Re: [Boost-users] multi_index_container

From: Aashit Soni (aks309_at_[hidden])
Date: 2006-02-17 03:28:47

Thank you for your quick response,

My intension about the comparision was to get some more functions with
which, i can squeeze performance from multi_index_container.
You are absolutely right that my comparision is not fair. I was
expecting lot of things at one go.

Still,  I need to add lot of functionality on top of my
multi_index_container to provide robust retrival and recycling. I
think The best thing is to test it is with full prototype
implementation. I will verfify and definately share you my experience
and test results. Because my existing implementation reclying is very
weak, and for my peformance testing i have disabled it. So the adverse
results are shown.

I will just write the code to set the load factor and equal_range()
retrieval. It may be possible i will finish my prototype and then will
swith to quantify for performance analysis. I must say it was to early
for me to say these result of multi_index_container as i am adding
extra overhead for one additional ordered list. This list is yet to
utilized.

I appreciate your support and time.

Thanking you,
aashit
On 2/17/06, Joaquín Mª López Muñoz <joaquin_at_[hidden]> wrote:
>
>
> Aashit Soni ha escrito:
>
> > 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.
>
> Well, it's hard to say. Note that if you're comparing a preexistent hash
> table with a multi_index_container composed of a hashed plus
> an ordered index, the comparison is not fair --the multi-index
> container is doing more work. On the other hand, it is perfectly possible
> that your previous hash container is just faster, but I don't think it
> can be *much* faster. If you can provide me (through the list or privately)
> with some test code I can take a deeper look.
>
> >  - 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?
>
> non_unique means equivalent elements (elements with the same key) are
> allowed into the container.
> In the particular case of hashed indices, equivalent elements are guaranteed
> to be adjacent.
>
> > When i call
> >  find and if the collisions are there i get the last inserted node,
> > how shall i get previously inserted nodes.
>
> Use equal_range() to get all of them. As explained above, equivalent
> elements are kept adacent.
>
> >  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.
>
> No such facility, sorry. This preallocation stuff is not in the spirit
> of node-based STL containers. You might gain some performance
> by using custom allocators specialized for small node requests:
> take a look for instance at boost::fast_pool_allocator:
>
> http://boost.org/libs/pool/doc/interfaces/pool_alloc.html
>
>
> >  I will just incorporate- your sugguesion and check how it is working.
> >
> >  Thank you once again, I really appreciate your time.
> >  regards,
> >  aashit
>
> Good luck,
>
> 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