Boost logo

Boost Users :

From: Aashit Soni (aks309_at_[hidden])
Date: 2006-02-17 00:59:23


Some correction!! in my previous mail.

 Thank you Mr Lopez,

> Slower in which aspect? Insertion, deletion, lookup?
 I have observed it is slower in insertion. I am roughly creating some
 200,000 entries into it. One entry is arround 10 Bytes of information. Each
 creation also creates some external objects to that are being cached
 in this container.

 - I am having iteration problem in hash -look up also. My hash index is
 non_unique. I am not sure how the collisions are handled? When i call
 find and if the collisions are there i get the last inserted node,
how shall i get previously inserted nodes.

 In some case, i need to reserve the space for the elements, So when i
 create my multi_index container, i want to tell it saying that i need
 x amount of space so please do the allocation and keep it ready. Is
 such facility available.

 I will just incorporate- your sugguesion and check how it is working.

 Thank you once again, I really appreciate your time.
 regards,
 aashit

> On 2/16/06, Joaquín Mª López Muñoz <joaquin_at_[hidden]> wrote:
> > Hi Aashit,
> >
> > Aashit Soni ha escrito:
> >
> > > Hi all,
> > >
> > > I am using multi_index_container on MSVC6, WinXP. I ported my existing
> > > Hash and order list to multi_index_container. which is working quite
> > > expected? a pure vanila hash_index with ordered_index
> > >
> > > I am facing some problem in fine tuning the hash_index which is slower
> > > compared to my previous implementation.
> >
> > Slower in which aspect? Insertion, deletion, lookup?
> >
> > > I am looking for different
> > > ways how can i fine tune the hash_index in multi_index_container?
> > >
> > > specifically i am yet to discover,
> > > How can i set the bucket size for the hash container?
> >
> > You cannot control bucket size explicitly. Hashed indices occupancy
> > level is controlled thru a parameter called load factor (lf) defined as:
> >
> > lf=size()/bucket_count()
> >
> > In general, the lower lf, the faster lookup operations are. You can set
> > the maximum value of lf to be allowed with max_load_factor():
> >
> > float mlf=c.max_load_factor(); // query max lf
> > c.max_load_factor(0.8f); // set max lf
> >
> > When the load factor reaches the specified maximum, the number of
> > buckets is automatically increased.
> > By default max_load_factor()=1.0. Lower this for faster lookup,
> > at the expense of more memory usage (more buckets.)
> >
> > > How can configure the container for maximum store it can reserve for
> > > me in one shot?
> >
> > Use rehash(), documented at
> >
> > http://boost.org/libs/multi_index/doc/reference/hash_indices.html#hash_policy
> >
> > prior to mass insertion of elements. For instance:
> >
> > // insert 1000000 elements. With lf=1.0, we will need 1000000 buckets
> > // so as to be under the specified max load factor
> > c.rehash(1000000);
> > c.insert(first,last);
> >
> > Doing a prior rehash is not necessary, but will save you some
> > intermediate automatic rehashings, pretty much the same way as
> > it happens with std::vector and reserve.
> >
> > > any other optimization parameter.
> > >
> >
> > Other than this, your best option is to choose a good hashing function.
> > The default is expected to work well except for exceptional
> > situations. You might want to use the hashing function used in your
> > previous Hash container so as to check out whether it does a
> > better job than Boost.Hash, although I'd say this is unlikely.
> >
> > > If any one has some idea. It will be of great help to me.
> > >
> > > regards,
> > > aashit
> >
> > Hope this helps a little,
> >
> > Joaquín M López Muñoz
> > Telefónica, Investigación y Desarrollo
> >
> > _______________________________________________
> > Boost-users mailing list
> > Boost-users_at_[hidden]
> > http://lists.boost.org/mailman/listinfo.cgi/boost-users
> >
>
>
> --
> A a s h i t
>

--
A a s h i t

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net