On 2010-06-15 10:44, Bjoern Michaelsen wrote:
Am Tue, 15 Jun 2010 09:18:45 +0200
schrieb Jan Holst Jensen<j...@biochemfusion.com>:
On 2010-06-15 09:06, Bartosz wrote:
By the way.
After replace svArrays by STL containers, in some cases I observed
boost of performance.
For example:
for (USHORT i = 0; i< aEntries.size(); ++i)
{
if (aEntries.at(i).aFntFmt == rFntFmt)
{
aRes = aEntries[i].aId;
break;
}
}
is much faster than:
USHORT nCnt = aEntries.Count();
USHORT i;
for (i = 0; i< nCnt&& 0 == aRes.Len(); ++i)
{
if (aEntries[i].aFntFmt == rFntFmt)
aRes = aEntries[i].aId;
}
If you're about to optimize then try the iterator-version of above as
well. Something like (not tested, off the top of my head, and I don't
know the actual type of aEntries):
EntryType::iterator end = aEntries.end();
for (EntryType::iterator i = aEntries.begin(); i != end; i++)
{
if (i->aFntFmt == rFntFmt)
{
aRes = i->aId;
break;
}
}
In some of the code that I work on (not OOo, but another C++ project)
I have seen a very nice performance boost by switching from
array-style subscripting to iterators.
Having measured performance on container access ad nauseum for
new_itemsets I can only warn you about such generic statements: For
example the new_itemsets cws seems to be 2-8% faster for loading and
saving on unix, while seeming to be ~8% slower on loading on windows
currently. So while measuring with callgrind is helping, it is only
part of the truth -- especially since it is partially synthetic. Also
measuring on a high-end i7 developer machine might be misleading,
since the scenario were we care about performance (meek netbooks etc.)
have completely different CPU-caches etc., resulting in possible
completely different performances.
Agree. I wasn't trying to make a generic statement, just pointing out
that it might be worth trying. And even though I have seen great
improvements in my particular release code on both Linux and Windows the
debug builds have terrible performance on Windows - which could be a
pain for developers.
Cheers
-- Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
