Re: Poor performance from stdext::hash_map

From: P.J. Plauger (pjp_at_dinkumware.com)
Date: 06/11/04

  • Next message: yux: "Is there some way to call virtual function in Destructor?" 
    Date: Fri, 11 Jun 2004 13:19:51 -0400

    "Andy Coates" <nothanks@nowhere.com> wrote in message
    news:%23H2Mnh6TEHA.3660@tk2msftngp13.phx.gbl...

    > I've just noticed that MS are now shipping hash_map and hash_set with
    > DevStudio. However, I'm finding that I'm getting worse performance than
    the
    > standard map container and a lot worse than the MFC CMap. So I'm assuming
    > I'm doing something wrong!

    This version of hash_map/set is unique in using incremental rehashing.
    The benefit is that there is never a point where the code suddenly
    decides to stop everything and rebuild the hash table completely.
    Equally, you never have to think about the circumstances under which
    you'd better force a rehash. Think of the difference between a car
    with automatic vs. manual transmission.

    What you've seen is the worst aspect of this automatic feature. As
    you grow the hash table, it has to incrementally rehash on a regular
    basis. There is a way to warn the container that it should be
    prepared to grow to a certain size, and hence save all that
    intermediate rehashing, but it's currently pretty clunky.

    The C++ committee is producing a (non-normative) Technical Report
    that adds tons of things to the Standard C++ library. Part of that
    tonnage is the template classes unordered_[multi]{map set}, which
    form a standardized replacement for the various hash containers
    knocking about. We've retooled the underlying machinery for our
    hash containers so that it serves equally well for the unordered
    containers in the TR. One benefit of that is the addition of a
    rehash function to *all* containers, old and new. When it
    percolates out to the field, you'll be able to assert manual
    control whenever you think it might help, and with much better
    notation than you currently have to use.

    P.J. Plauger
    Dinkumware, Ltd.
    http://www.dinkumware.com

  • Next message: yux: "Is there some way to call virtual function in Destructor?"

    Relevant Pages

    • Re: Newbie question :) be kind...
      ... measuring system as a thing in itself, ... Consider the standard intermodal shipping containers. ... I liased with New Zealad Railways to move containers around the country. ... Most tunnels would clear the ...
      (rec.models.railroad)
    • Re: Which STL should I use?
      ... Many people still use it, however, the correct term is "Standard C++ Library". ... Various iterator classes allow to manipulate content of containers. ... std::deque tries to take best of both worlds providing relatively fast access to an element and addition/removal from/to ends of container. ...
      (microsoft.public.vc.language)
    • Re: Which STL should I use?
      ... STL is an old name that stands for "Standard Template ... Containers and iterators. ... This part was standalone addition to STL until recently. ... providing relatively fast access to an element and addition/removal ...
      (microsoft.public.vc.language)
    • Re: Forth and Unix -- history
      ... However, members of the TC had recent or current experience with processors with 4-bit AUs and 16-bit AUs, not to mention 32-bit characters. ... Forth provides handlers for containers of whatever size is useful on a particular architecture, but does not attempt to prescribe the nature of the content of those containers. ... But here's a case where Standard Forth is very irregular, ...
      (comp.lang.forth)
    • Re: Unified Ada library
      ... :> developers who think that the STL could only have been written in C++, ... Could you comment on the importance of iterators and generic ... we cannot present a standard interface to containers ...
      (comp.lang.ada)