12/19/2007 1:01 PM
OS Benchmarking for 6.4 vs. 6.3.0
I've got a customer who's interested in making the switch from 6.3.0 to 6.4 when it's available. Two very key metrics
for them are boot time (time to get their application up & running) and memory consumption (they're very close to the
limit for this product line). Related to this is the smallest amount of free RAM that the kernel expects before it will
stop running properly.
They made a similar switch for their 6.2.1B product to 6.3.0. What they discovered was that in optimizing the 6.3.0
memory allocator for speed in normal use, the changes negatively impacted total system ram used as well as time required
to start applications. The reasoning had to do with default heap blocks and/or some extra work done by the allocator
during initialization. Thankfully they were able to substitute the 6.2.1B allocator for the stardard one provided by 6.
3.0 to get their old behavior. Which ensured that they still met their startup requirements *and* could still fit into
So two questions.
1) Are we going to benchmark things like startup time and overall memory use of 6.4 against 6.3.0? Clearly we can't do
it for specific customer applications. But will we have any idea what we've done and how it impacts various classes of
user applications? Like small, big but flat, big but using lots of .so's (like C++)? Exampnles of things customers
will need to know would be size of increase or decrease per malloc/per thread/per process.
2) Will we be able to use the old allocator from 6.3.0 or even 6.2.1B if necessary if the 6.4 allocator introduces some