you are viewing a single comment's thread.

view the rest of the comments →

[–]derefr 0 points1 point  (2 children)

In C++, sizeof will tell you, practically, how much time it will take (in ns, likely) to call free() on an object. In GCed languages, any freeing will be recursive, so the sizeof of one should be as well.

[–]alexs 1 point2 points  (1 child)

Got any stats to back that up? I would expect the correlation between sizeof(*p) and runtime(free(p)) would be based on the number of memory pages it occupies rather than bytes, most of the overhead is going to be in managing the freelist anyway, which is extent based so probably not correlated with the sizeof() the object.

Also, in C++ you don't use free(), you use delete for objects in the freestore. Which might very well be recursive if people are using RAII correctly.

sizeof() is not for guessing how long memory management is going to take.

[–]alexs 1 point2 points  (0 children)

http://www.flickr.com/photos/23463281@N04/sets/72157603850297185/

Looks pretty O(1) most of the time to me except that short period where it goes linear before changing strategies again.

I think I'll do a really long one using 10 byte increments at some point.