[Debtags-commits] [svn] r1600 - in tagcoll/trunk: . tagcoll

Enrico Zini enrico at enricozini.org
Tue Feb 21 18:54:57 UTC 2006


On Tue, Feb 21, 2006 at 07:30:50PM +0100, Peter Rockai wrote:

> > +	mutable std::vector<std::string> stringCache;
> > +	virtual std::string operator()(const int& id) const
> > +		if (stringCache[id].empty())
> > +				stringCache[id] = std::string(s, size(id));
> > +		return stringCache[id];
> I have dropped exactly this optimisation for component::Packages just a while
> ago (contemplating that the speed-memory tradeoff is not worth it -- my case
> is roughly 20k strings which amounts to over 100k overhead which is 50 pages,
> with rather conservative guesses). How did this reflect in the hard numbers? I'm
> not completely convinced of the incremental resizing either, maybe a resize
> up-front would be better? the directly allocated memory for string is fairly
> small, and resize() could trigger memory copies (since vector::iterator is a plain
> pointer)... It's not overly likely, so probably just show me the numbers :).

No memory copies this time because the vector is presized at creation
(check the constructor).

It brings the output() test down from 7360ms to 5550ms and slightly
makes the other tests faster, but I'm doubtful about that optimization
as well.  For two reasons:

 1. It's optimization for a specific use (i.e. creating strings, and
    having memory to trade)
 2. StringIndex is only used in tagcoll tests

I did it mainly as a curiosity to see how string creation would impact
performance, but I'm happy to revert it at any time.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20060221/a460473e/attachment.pgp


More information about the Debtags-devel mailing list