Re: [Boost-bugs] [Boost C++ Libraries] #4220: Performance of erase in multi-index-container

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #4220: Performance of erase in multi-index-container
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2010-05-16 19:00:25


#4220: Performance of erase in multi-index-container
------------------------------+---------------------------------------------
 Reporter: Rohit Joshi | Owner: joaquin
     Type: Support Requests | Status: new
Milestone: Boost 1.43.0 | Component: multi_index
  Version: Boost 1.42.0 | Severity: Optimization
 Keywords: |
------------------------------+---------------------------------------------

Comment(by Rohit Joshi):

 Replying to [comment:3 anonymous]:
> Replying to [comment:2 joaquin]:
> > That was my hunch at first also, but the test shown as stackoverflow
 uses the size_type erase(const key_type& x) version of erase, not the
 problematic one. I've just posted there a guess along a different line.
>
> Thx for your reply. yes, possibility of m_nTransactionHandle could be
 same value and that's why I have used it as hash_non_unique. But primary
 index m_nId is hashed_unique (no duplicate) and I am using that to erase
 from container. I think non-unique/secondary index values shouldn't impact
 performance while erasing entry via a primary hashed index. Anyway, I will
 try that out and let you know.


 Yes, when I make 2nd index hashed_unique, performance increased
 drastically. Than I tried 2ns index as ordered_unique and
 ordered_non_unique and performance was similar to hashed_unique. So I
 don't understand why hash_non_unique looses performance even though I use
 primary key hashed_unique to erase the objects. I have posted a link on
 stackoverflow (It seems I can't post a link here) for performance test
 results. Thx for your help.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/4220#comment:4>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.

This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:03 UTC