Min/Max Functions Cause Double() Memory Leak When Used In Loops

  1. ‹ Older
  2. 2 weeks ago

    Alex B

    Aug 5 Pre-Release Testers, Xojo Pro Canada

    @Julian S Interesting, not sure then, a simple project with it happening would be useful, maybe pop a ticket in with the project attached as you mentioned above, I certainly can't think what could be causing it at this hour of the morning :)

    Yeah, just a button with the code mentioned is enough to cause the leak, happens in both Web and Desktop.

  3. Alex B

    Aug 5 Pre-Release Testers, Xojo Pro Canada

    I assume it has something to do with ParamArray taking in a blank array of doubles, but not getting destroyed by the ARC GC.

  4. Norman P

    Aug 5 Pre-Release Testers, Xojo Pro great-white-software.com/blog
    Edited 2 weeks ago

    I'd want to see actual code for this
    I'm sure there' lots of code that uses loops doubles and min max and I dont see anyone else reporting this as an issue

  5. Julian S

    Aug 5 Pre-Release Testers, Xojo Pro UK

    @Alex B Yeah, just a button with the code mentioned is enough to cause the leak, happens in both Web and Desktop.

    The code mentioned doesn't work and I don't really want to guess your variable types as that might be part of the issue :)

  6. Norman P

    Aug 5 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    new desktop app
    add push button to the window
    in ots action event put

    System.DebugLog Str(Runtime.MemoryUsed)
    
    For i As Integer = 1 To 1000
      Untitled(1,0,2,2)
    Next
    
    System.DebugLog Str(Runtime.MemoryUsed)

    add a method

    Private Sub Untitled(ParamArray data as double)
      // Dim width As Double
      // Const bar_width = 123
      // 
      // For i As Integer = 0 To Min(Width/BAR_WIDTH,Data.Ubound)
      // 
      // Next
      
      
    End Sub

    run a few times and push the button :P
    seems to have nothing to do with min max etc just a paramarray

    fun find
    that would explain why this is not seen in other code I'm familiar with
    it doesnt use paramarrays

  7. Norman P

    Aug 5 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    lest you think "Oh no problem I'll ditch the paramarray and use one I allocated"
    swap the button code for this

    System.DebugLog Str(Runtime.MemoryUsed)
    
    Dim d() As Double = Array(1.0,0.0,2.0,2.0)
    For i As Integer = 1 To 1000
      Untitled(d)
    Next
    
    System.DebugLog Str(Runtime.MemoryUsed)

    and alter the method to

    Private Sub Untitled(data() as double)
      
    End Sub

    run a few times again

  8. Alex B

    Aug 5 Pre-Release Testers, Xojo Pro Canada

    Interesting...

    for i as integer = 0 to min(1,1)

    Creates 1 double()

    for i as integer = 0 to min(100,100)

    Creates 100 double()

  9. Alex B

    Aug 5 Pre-Release Testers, Xojo Pro Canada

    Sample Project, changing the numbers in the Min(1,1) to something else will create that many Double() arrays.

    https://static.craftymynes.com/LeakTest.xojo_binary_project

  10. Norman P

    Aug 5 Pre-Release Testers, Xojo Pro great-white-software.com/blog
    Edited 2 weeks ago

    the ENDING loop condition is evaluated EVERY TIME through the loop
    so with min(100,100) it evaluates min(100,100) each time which creates a new object
    the first doesnt because N is computed ONCE
    use the first form and you're fine
    you can see it if instead of MIN you do this in pushbutton1

    Dim n As Integer = foo(100,100)
    
    for i as integer = 0 to n
      
    next
    
    CountDoubles

    and this in pushbutton2

    For i As Integer = 0 To foo(100,100)
      
    next
    
    CountDoubles

    and defined foo as

    Public Function foo(d1 as double, d2 as double) as double
       System.debuglog currentmethodname
      return min(d1,d2)
    End Function

    FWIW this is expected and has been long standing behaviour
    Dont expect it to be changed

  11. Julian S

    Aug 5 Pre-Release Testers, Xojo Pro UK

    Old bug I'm afraid, nice to see Xojo on the ball... 2015 :(

    Feedback Case #40114

  12. Norman P

    Aug 5 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    and dead easy to work around

    precompute the loop bounds

  13. Alex B

    Aug 5 Pre-Release Testers, Xojo Pro Canada

    @Norman P and dead easy to work around

    precompute the loop bounds

    Yeah, I figured that out, just wanted to share for anyone else who might have the same issue.

  14. Alex B

    Aug 5 Pre-Release Testers, Xojo Pro Canada

    @Julian S Old bug I'm afraid, nice to see Xojo on the ball... 2015 :(

    Feedback Case #40114

    Voted!

  15. Julian S

    Aug 5 Pre-Release Testers, Xojo Pro UK

    It boggles my mind that something like that would be knowingly left in for 4+ years.

  16. Anthony C

    Aug 6 Pre-Release Testers, Xojo Pro GraffitiSuite Developer
    Edited 2 weeks ago

    @Julian S Old bug I'm afraid, nice to see Xojo on the ball... 2015 :(

    This behavior is actually a LOT older than that. It's always been recommended that you compute loop bounds before your For...Next statement for this reason (at least as far back as I can remember). Doing things like:

    For i as Integer = 0 to arrayOfItems.Ubound

    Independently loops through arrayOfItems on each iteration of the loop to get the last index for that trip through the loop, as Norman said above. The fact that it creates these objects and leaves them in memory is nasty, but a side effect of the same. I'm sure there are other areas where this leaks memory if you use certain methods to calculate your bounds within the For... line.

    See Performance Considerations

  17. Sascha S

    Aug 6 Pre-Release Testers, Xojo Pro Germany, Lower Saxonary

    @Julian S It boggles my mind that something like that would be knowingly left in for 4+ years.

    Feel like this is often with Xojo Bugs "if there's an easy woraround, we do not need to fix it. Users should simply learn how to use our Tool..."...

  18. Sam R

    Aug 6 Pre-Release Testers, Xojo Pro Hengchun, Pingtung, Taiwan

    Personally I found for performance that NOT using min or max was faster, instead using a simple equation like below.

    X = if( x < y, x, y )

    In other languages this can be written

    x = ( x < y ) ? x : y ;

    In regards to using it in a loop; old habits die hard.

    Dim n as integer = <countEquation>
    Dim l as integer
    For l = 0 to n
        ~ do stuff
    Next
  19. Norman P

    Aug 6 Pre-Release Testers, Xojo Pro great-white-software.com/blog

    @Sam R In regards to using it in a loop; old habits die hard.
    Dim n as integer = <countEquation> Dim l as integer For l = 0 to n ~ do stuff Next

    pluses - the end of loop condition is evaluated ONCE
    if thats a function that does a lot of work then that could be a big plus

  20. Julian S

    Aug 6 Pre-Release Testers, Xojo Pro UK
    Edited 2 weeks ago

    @Anthony C This behavior is actually a LOT older than that. It's always been recommended that you compute loop bounds before your For...Next statement for this reason (at least as far back as I can remember). Doing things like:

    For i as Integer = 0 to arrayOfItems.Ubound

    Independently loops through arrayOfItems on each iteration of the loop to get the last index for that trip through the loop, as Norman said above. The fact that it creates these objects and leaves them in memory is nasty, but a side effect of the same. I'm sure there are other areas where this leaks memory if you use certain methods to calculate your bounds within the For... line.

    See Performance Considerations

    I'm not on about the speed issue, I'm on about the leaking issue, the way someone codes shouldn't determine if the program will eventually crash due to no fault of their own.

    @Sam R Personally I found for performance that NOT using min or max was faster, instead using a simple equation like below.

    X = if( x < y, x, y )

    Indeed, dipping into a function a few thousand times in a loop would always be worse than what you posted if the compiler didn't flatten it out. Macro's would be nice, but we can dream.

  21. Anthony C

    Aug 6 Pre-Release Testers, Xojo Pro GraffitiSuite Developer

    @Julian S I'm not on about the speed issue, I'm on about the leaking issue, the way someone codes shouldn't determine if the program will eventually crash due to no fault of their own.

    Totally agree, just pointing out why it was likely never fixed as the leak only seems to happen (according to my tests) when using Min/Max in this specific way.

or Sign Up to reply!