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
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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- A a s h i t