This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: std::string::reserve()


Neil Ferguson wrote:

Can you make a bugzilla report about this?

Will do - tonight, after the meeting I'm about to have. Do you want the old patch included in the bugzilla report?

Yes, while you are at it, thanks in advance.


More specifically, I don't like the idea of, so to speak, anticipating in reserve the intentions of _M_clone , using at this upper level of abstraction a knowledge of _M_clone inner logic... Please, let me think about this issue a little more...

I vaguely seem to recall lifting out the size calculation logic into a separate method, so _M_clone and reserve could both call on it from one place, if that helps any.

Sure, I remember that, nice. Still, in a sense we would do work in reserve which more properly belongs to _M_clone. Or, in other terms, we would compute rounded sizes two times, at two different levels of abstraction... something sounds wrong ;) We'll see...


One result of this is that the exponential allocation policy can end up allocating substantial amounts of memory which gets left unused, and it would be nice to have the option of reclaiming it this way.

Definitely. Now we shrink to exact fit anything smaller than a memory page.


By the way, why don't you experiment a bit with changing the grow factor from 2.0 to 1.5, in _S_create? In some preliminary tests of mine the performance are not seriously affected while the amount of memory allocated decreases...

Paolo.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]