Forum Discussion
chrisb has a good point with memory leaks.
I'm currently testing a Delphi application. Certain objects are transient during a run, cannot be reliably mapped, and have to found during a run.
One such item is a popout menu that is generated from a TreeView node, which can be several levels deep. Each level has to be searched for at runtime as it is spawned.
I noticed it taking longer and longer to find them.
When I inspected the object model, there were thousands of ADODB connection objects floating around in the background that the application was not disposing of properly. It had probably been doing this for years. They were eventually killed when the module was closed (the module is launched from out primary application).
But no-one had ever noticed this. On a larger scale (such as if it had been happening in the main application rather than the smaller Delphi executable it launches) this could have led to far worse memory consumption and performance. Have seem similar things with web based applications as well. Worst one was capable of locking up my machine (i7 with 8gb RAM at the time) with 40 minutes of constant running as it was so bad.
So yeah, definitely something you should consider looking into. Especially on a VM where problems like this can be magnified if they are not allocated enough resource both in themselves and their hosting environment.
Colin_McCrae Thats interesting. I hadn't thought of the difference between name mapping and finding objects on the fly. I did away with name mapping and find all my objects on the fly as the test is running. I'd assume finding them on the fly is way more resource intensive. Perhaps this is something SmartBear doesnt even test too much as they seem to encourage users to use namemapping.
Related Content
- 4 years ago
- 5 years ago
Recent Discussions
- 2 hours ago