Re: Adding an associated reference is memory expensive (was: Adding an observer is memory expensive)
Re: Adding an associated reference is memory expensive (was: Adding an observer is memory expensive)
- Subject: Re: Adding an associated reference is memory expensive (was: Adding an observer is memory expensive)
- From: Greg Parker <email@hidden>
- Date: Sat, 12 Sep 2009 01:58:30 -0700
On Sep 12, 2009, at 12:59 AM, Kai Brüning wrote:
On 12.9.2009, at 00:35, Greg Parker wrote:
We have your earlier report rdar://7212101. Thanks, Torsten. (Ken
didn't see it because the bug didn't pass through his group's hands
on its way to my group.)
This is a bug in the associated reference machinery. That code
keeps a C++ std::hash_map per augmented object, mapping associated
keys to associated values. std::hash_map uses an std::vector
internally, and the default hash_map constructor pre-allocates 100
entries for that vector.
Which are then raised to 193 by __stl_next_prime() in hashtable.h.
Times the 64 bit pointer size makes 1544 bytes, which GC seems to
round up to the 2k seen by the OP.
This is overkill for associated objects usage. The fix is to use a
non-default constructor that specifies a much smaller initial
hash_map size.
Unfortunately constructing the std::hash_map with a small capacity
will lower the number of preallocated bucket slots only to 53 (->
424 bytes under 64 bits), because this is the smallest number
returned by __stl_next_prime(). (I deduced this from the stl source
in the 10.6 sdk, so I may be mistaken.)
We discovered that today as well. Next option is to use a non-STL hash
implementation; I hear LLVM has a good one internally.
If anyone has a real app - not just a constructed test case - whose
memory usage or performance is significantly worse on Snow Leopard
because of this, please file a bug report. The software update process
is a naturally conservative one. The risks of invasive changes (like
swapping out a hash table implementation) are much easier to justify
when they help fix real problems in real apps.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden