I use GlowCode for profiling ObjectARX applications. As far as I know, this is the only profiler that works with AutoCAD. What makes GlowCode special is that it can instrument code on the fly, including a monster like AutoCAD. It has a clunky interface that takes some patience to figure out, but it’s a lifesaver when you need it.
Recently a CADLock customer sent us a drawing file that was apparently not very complicated, yet it took over 20 minutes to create a deep vault. To determine the cause, I used GlowCode to profile the vault creation process. I could see almost immediately that most of the time was being spent in AcDbObjectId::operator ==, which was being called from AcDbObjectIdArray::find.
This turned out to be a classic case of using the wrong type of container. Searching an AcDbObjectIdArray isn’t bad when the array is small, but this drawing contained a special case where the array was very large, and this special case exposed the flaw. I changed the array to a std::set and tested again. The new time was 30 seconds to create the vault — a slight reduction of approximately 95%.
[Full Disclosure: Electric Software has for many years provided me with a complimentary license of GlowCode in exchange for my testing and feedback.]
6 thoughts on “GlowCode Success Story”
Sorry to contact you like this, but, I haven’t found your mail anywhere. Also, sorry if you’re not the Owen Wengerd I’m looking for.
My question is – have you, by any chance, managed to make VS2010 Platform Toolset for VS2003 work?
No, I have not. VS 2003 and VS 2002 will require either some preprocessing to convert the response files to ANSI, or a VS 2010 service pack that adds back the non-Unicode response files feature. I’ve been doing some work on this as time permits, but I have nothing yet.
Are you, perhaps, willing to share what you have by now?
Please email me (firstname.lastname@example.org).
Sorry for this approach for asking you help.
I am trying to run Glowcode profiler on a sample ARX project. Before trying on an ARX project, I was able to use glowcode profiler to spot lines of code that caused memory leaks in my test Win32 DLL that was being consumed by my test Win32 console application.
However, I am unable to get similar results with my sample ARX project, which upon executing a command in AutoCAD’s command prompt will allocate a new string in heap and will not delete. Upon running the profiler in this project with same steps as I did for my console application, I could see a lot of leaks, but none lead to my code.
I guess I am doing something wrong. I could not figure out how many times I do this and hence thought of seeking your help in knowing the steps/tips for profiling an ARX project.
This is a good question. Unfortunately I don’t have any good answers. There is just no straightforward way to separate a single module from an entire application that shares the same retail C runtime when it comes to memory allocation. I’ve always built memory tracking diagnostics right into my code, so I’ve only ever used GlowCode for general memory tracking and relied on my own diagnostic code for specific memory leak detection. Having said that, the GlowCode approach of instrumenting at runtime is the best possible chance of solving this difficult problem, and although there are no simple answers, I’m sure there are techniques for using GlowCode to help detect ARX memory leaks. This would be a good topic to explore in a future blog post.