-
François ROSSIGNOL
- PowerBuilder
- Friday, 12 March 2021 12:53 PM UTC
Hi,
we're concerned with the memory usage our our latest powerbuilder application.
It was originally build with PB17R3 and is now running with PB19R2.
It has been migrated to PB19R3 for memory testing purpose but the results are the same.
the application is 32 bits
The application is built over our homebrewed framework (which certainly contains some design flaws).
It contains quite a bit of overhead and services.
Here is the tests we're using.
Open 10 times the same window
Close all the windows
Open the same window 10 times
Close all windows
Rince and repeat.
When closing the windows some of the consumed memory is freed but not all ot it.
Each time we lose between 3 and 10 MB of RAM.
Use it long enough it consumes hundreds of MB of RAM when a freshly openned app consumes around 70 MB.
It's the same whether the app is compiled in p-code and ran from the IDE.
Sometimes (but rarely) I can open the windows without additionnal memory usage.
Sometimes (but very rarely) additionnal memory will be randomly be freed.
If the app is ran from the IDE when you close the app and return to the IDE, PB190.exe still has a high memory usage.
I'm having a hardtime identifying the leak, I tested old version of the app the problem was present from the begining but was less severe.
Let's say before opening the windows I had a 100MB memory usage
I open the windows and it goes up to 150MB
I close all the windows memory goes back to 103MB
But sometime it'll briefly drop back to 100MB and going up to 103MB
Is there a tool to see the memory consuption of each object in memory ? Or any other tool that might be
The usual suspects
I checked the code each CREATE is matched with a DESTROY
each openUserObject is matched with a closeUserObject
I used CDMatch to check I don't have npt destroyed objects
Interrestingly I have a bunch of destroyed object which are not created.
They're all autoinstentiated nvos and structures, could this be part of the problem ?
The master datawindow and datastore objects have a this.reset() and this.dataObject = "" in the destructor event
I red in a previous post something about arrays
String ls_col1[], ls_null[]
//populate your array, then finish with
ls_col1 = ls_null
I'm currently working on that but it's going to take some time because we have a lot of arrays used in the framework.
We already use UseHwnd=no in the pb.ini
I also tried that
However, a neat little trick I used to use is to momentarily minimize the PB App (say on an IDLE event) by using the SEND command. If you send a Minimize to the MDI Frame window, do a a few yields and the then send he MDI Frame a "restore" command ... I have found that the PBVM would actually release memory that is marked as "free".
That didn't do the trick, plus it's really annoying having the application pop back in the front when you're not using it.
more and more of our customers uses RDP connexions to run the app therefore there's limited ressources per user.
meaning once the leak is fixed we'll try to tackle overall memory usage for the application.
I tried to throw some additionnal GarbageCollect
Now I have a few more questions about memory management and memory usage:
Does readonly argument versus by value make a difference ?
In a some of our service objects arguments for objects are by value where they should be by reference (because those objects are modified) but even if they're passed by value they're still correctly modified. The resaon they're passed by value is because I can't do a my_service_object.of_function(this) when calling it from let's say my master datawindow.
Does that have an impact on memory management. And what would be the correct way to do things ?
We do have "read-only" datawindows but it's safe to assume some of them have update properties set. is there significant impact here ?
what else should I be on the lookout for ?
Thanks in advance
Regards,
François
Find Questions by Tag
Helpful?
If a reply or comment is helpful for you, please don’t hesitate to click the Helpful button. This action is further confirmation of their invaluable contribution to the Appeon Community.