Performance Quiz #6 -- Conclusion, Studying the Space

LogDump: CLRProfiler Log analysis tool

Rico Mariani's Performance Tidbits — Tue, 09 Aug 2005 04:07:35 GMT

Ever wonder how I produce nice textual allocation summaries like this one?

This report shows allocations...

re: Performance Quiz #6 -- Conclusion, Studying the Space

ricom — Sat, 21 May 2005 09:48:28 GMT

As far as object overhead goes, compared to C++ it's only 4 bytes more per object for normal objects. It may be less if you consider overhead imposed by your allocator.

This example is particularly bad because the C style strings aren't objects and they have the length stuff in managed code because they are variable length, and they're small strings.

But really, it's never been a good idea to allocate lots of small objects.

I could nix that overhead if I wanted to -- keep the char buffers for instance and do basically what you'd do in C. I chose to eat the tax in this case.

Whether or not you get a lot of overhead depends on if you build crazy object graphs or not :)

re: Performance Quiz #6 -- Conclusion, Studying the Space

Will Dean — Sat, 21 May 2005 09:01:57 GMT

I expect that you've read this:

http://www.sysinternals.com/blog/#111363926377819242

In some ways, he could be said to be illustrating your point that doing nothing with the framework makes it look bad.

However, as he points out, the badness seems to continue on up as the applications get more complex. Is this likely to be largely due to the significant per-object overhead?

But maybe it doesn't really matter...

re: Performance Quiz #6 -- Conclusion, Studying the Space

ricom — Sat, 21 May 2005 04:33:43 GMT

No problem, I deleted the extra copy for you.

When Raymond returns from vacation he might have some useful insights into why he did things the way that he did them. I have some guesses but it's total speculation. Let's see what he says :)

re: Performance Quiz #6 -- Conclusion, Studying the Space

Thomas — Sat, 21 May 2005 03:48:55 GMT

[Note: I accidently posted this same message in the previous blog about this, before I noticed this followup. Sorry for that.]

Rico,

I'm suprised that Raymond jumps down to the C level so quickly. He went straight to raw string pointers instead of just having a vector pointers to entries. He didnt consider using a boost memory pool to store said entries and then having the vector as an index sorta.

All in all while I agree that the CLR is excellent at these memory allocation intensive scenarios, it seems to me that Raymond didn't really harness the power of the STL and boost all that well.