Re: STL Slow - VS2005

Tech-Archive recommends: Speed Up your PC by fixing your registry

Yes, but I am microbenchmarking a small subset of the STL string
implementation only. Most real world apps will have bigger bottlenecks to
deal with and these benchmarks will not matter much. The benchmarks do
point
to a more efficient implementation in STLPort.

Do they really?
Imagine you are implementing list.
What will you do in the allocator?

1) Will you "remember" previous nodes on deallocation?
2) Will you free previous nodes on deallocation?

1) and 2) are mutually exclusive.
1) will give fast node reuse but heap memory use will increase
2) will give slower node reuse but heap memory use will be minimal as it is
recycled.

Your tests are too simplistic.
They don't measure how well implemented the library designers have been over
their STL.
Instead they measure the default choice of allocators that comes
out-of-the-box with compiler.
I am certain that accounts for your performance difference.
Your seeing the usual space-versus-time tradeoffs that we all know.

Now I know that Dinkumware sells some add-on package that gives you various
different drop-in replacement allocators. And similarly STLPort also has
alternative allocators if it matters that much.

There is no right-or-wrong here. I think you will find that STLPort has a
bigger footprint in terms of memory consumed - nothing wrong with that, it
is the library choices made. If it was a 16-bit enviroment or embedded ROM
enviroment that might be the wrong choice.

If there is any fault, I blame the C++ standard because apart from limited
control over vector, deque and string; it is impossible for the programmer
to inform the library designers what their intention is with a container. If
your application uses large amounts of heap memory between several
containers, enough to bust OS limits , you don't want any container to
reserve spare memory for later use. And contrarywise if you are constantly
reusing a container which grows and shrinks, for performance reasons you
want it to recycle the same memory again and again.

I would consider the default allocator out-of-the-box as part of tests but
it would be the only thing I would look at.
I would _ALSO_ like to make some tests that are allocator-neutral and also
don depend on the choice of growth factor for vector, string. You have not
done that.

And I can beat STLPort in terms of your tests with my STL implementation
I would make the growth rates of vector, string, deque, stringstreams be 64
times whenever capacity is reached.
The small-string-optimisation for string - I would ensure there is space for
1K right form the outset.
So at a bare minimum sizeof(std::string) would be 1024. The strings would be
obese.
But the cost of this astronomic. The memory footprint is huge.
By your criterion, your tests are likely to reveal that my STL
implementation is the most "efficient" out.
But it would be a poor conclusion drawn from oversimple tests.

Stephen Howe


.

Relevant Pages

  • Re: size_t and size_type
    ... The Standard explicitly allows container ... If there are any such implementations, I don't know about them yet. ... Either they were thinking ahead to some scenario when containers' memory ... of allocators in the first place. ...
    (comp.lang.cpp)
  • Re: Fast string operations
    ... Looping: I thought looping over arrays in managed code was "slow" ... array handling and such. ... The problem with TrimHelper is that it always returns a new string instance. ... The customer perceives this as a memory leak. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Discovering variable types...
    ... >- but I suppose MS expect us to use wrappers ... memory allocations for your variables from disk as well. ... >They most certainly are of fixed size, changing the size of a String ... >>me to keep buffer size and current postion right in the memory block. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Optimize
    ... if you use it like me to get 'the next string ptr' in addition. ... | |mov ebx eax;dw aligned strings are faster ... | Would it be enough to touch each 16th bytes in the 64K memory area ... Cache-line size is fixed, my AMD got 64 bytes per line. ...
    (alt.lang.asm)
  • Memory Question
    ... I have wrote a helper to my program which monitors object count, memory utilization and a threshold of 10% to determine how many objects are sticking around and how many are being garbage collected. ... occured right before the original String count). ... def print_threshold_breakers hsh1, hsh2, threshold ... putsf 'Building mem usage', mem_usage ...
    (comp.lang.ruby)