Re: [dev] Re: BigPointerArray, SvPointerArray vs STL containers
Getting rid of SvArray might not be enough alone to fix this, but it
would be a big step in the right direction. Please also have a look at
the work in cws new_itemsets which tries to get rid of the old
SfxItemSet implementation and replace it with stl container-based stuff
whereever possible. Changing such a fundamental datastructure is not
easy at all, but the new implementation is mostly stable by now -- only
a few minor glitches remaining.
Where I could find the cws new_itemsets?
Please specify link to it.
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 nCnt0 == aRes.Len(); ++i)
{
if (aEntries[i].aFntFmt == rFntFmt)
aRes = aEntries[i].aId;
}
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: BigPointerArray, SvPointerArray vs STL containers
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.
Cheers
-- Jan
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: BigPointerArray, SvPointerArray vs STL containers
On 06/15/10 09:06, Bartosz wrote:
Getting rid of SvArray might not be enough alone to fix this, but it
would be a big step in the right direction. Please also have a look at
the work in cws new_itemsets which tries to get rid of the old
SfxItemSet implementation and replace it with stl container-based stuff
whereever possible. Changing such a fundamental datastructure is not
easy at all, but the new implementation is mostly stable by now -- only
a few minor glitches remaining.
Where I could find the cws new_itemsets?
Please specify link to it.
Childworkspaces may be found like this:
Code repository at
http://hg.services.openoffice.org/hg/cws/new_itemsets/
Additional information (EIS) at
http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Path=DEV300%2Fnew_itemsets
Ruediger
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 nCnt0 == aRes.Len(); ++i)
{
if (aEntries[i].aFntFmt == rFntFmt)
aRes = aEntries[i].aId;
}
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
[dev] Re: BigPointerArray, SvPointerArray vs STL containers
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.
Best Regards,
Bjoern
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: BigPointerArray, SvPointerArray vs STL containers
On 14.06.2010 12:01, Caolán McNamara wrote: On Mon, 2010-06-14 at 11:22 +0200, Michael Stahl wrote: the SvArrays should be replaced by appropriate STL types (mostly vector, i guess, but probably in some cases stacks or deques or something else). deques I think was the best option in general the last time I looked at this. Probably best to ignore the binfilter ones and leave those still using a migrated-into-binfilter svarray family. I thought I had a patch somewhere to do some of the conversion, but I can't find it now. I remember that I didn't go ahead with it at the time because my first cut at it left OOo larger than it was before hand, which was an annoying result. A code replacement like this creates the question what shall be the goal: - reduce memory footprint - improve performance - remove code duplication - improve code quality etc. IMHO in case of the move from SvPointerArray to STL containers the predominat factors will be the soft ones, not the hard ones that are easy to measure. Even without memory footprint and performance improvements in the first place a change like this has its merits. Though it also has its price (the working time to invest), what might explain why nobody started that effort. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] SfxItemSet assumptions and assertions
On 14.06.2010 17:49, Malte Timmermann wrote: Björn Michaelsen wrote, On 06/14/10 16:09: Am Mon, 14 Jun 2010 15:11:57 +0200 schrieb Malte Timmermannmalte.timmerm...@sun.com: Hi Bjoern, Björn Michaelsen wrote, On 06/14/10 13:34: Hi all, while testing the new SfxItemSets in cws new_itemsets I came across a few interesting uses of itemsets which I had considered to be illegal (but I might be wrong there). I assumed: - non-void items should only be put at the same which id in a set as the which id on the item itself. - void items should always have a which id of 0 and are allowed to be put anywhere. Who says they would need to have which ID 0 ? Well, as I said I can be wrong here. But a SfxVoidItem with which id set to 0 is interpreted as disabled. However, some functions only test for the type being SfxVoidItem, while others test only for the which id being 0. Thus having a half-disabled item might lead to interesting results. See for example: http://svn.services.openoffice.org/opengrok/xref/DEV300_m82/svl/source/items/itemset.cxx#542 (SfxItemSet::GetItemState) http://svn.services.openoffice.org/opengrok/xref/DEV300_m82/svl/source/items/itemset.cxx#589 (SfxItemSet::Put) http://svn.services.openoffice.org/opengrok/xref/DEV300_m82/svl/source/items/itemset.cxx#2040 (SfxItemSet::DisableItem) So, when you used SfxVoidItems, did you intend them to be interpreted as disabled? No - but it doesn't matter, because I only use them for character attributes (single items), not for paragraph attributes (item set). They probably only get into the item sets because the SfxItemPool has default items, I don't think that I put them in some SfxItemSet explicitly. So this is code broken (the code in the ItemSet, not yours). If some code in SfxItemSet just checks for SfxVoidItems to decide whether it is a disabled item, while other code just checks for ID == 0, the problem is already there. It's also an unnecessary complexity to require the check of two attributes (type *and* ID). The next interesting question is what should happen if items derived from SfxVoidItems are used ... So perhaps coding disabled as SfxVoidItem is a severe design flaw. So it would be better if disabling (and checking for disabed state) should be possible only by using explicit methods from SfxItemSet. If the implementation requires to code that by storing a special item, this item should be a private class in SfxItemSet so that it can't be used outside. The problem with that approach is that it requires a non-trivial amount of work. :-( Of course they get into the SfxItemPool... BTW - they are also used in the binary document format, SfxItemSet load/store, so I also don't know what would happen here if the IDs where 0. So we are lucky that this format is doomed. :-) Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to nospamfor...@gmx.de. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: BigPointerArray, SvPointerArray vs STL containers
On 2010-06-15 10:44, Bjoern Michaelsen wrote:
Am Tue, 15 Jun 2010 09:18:45 +0200
schrieb Jan Holst Jensenj...@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 nCnt0 == 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
Re: [dev] Re: CMake
Am Mon, 14 Jun 2010 14:13:36 -0400 schrieb Bill Hoffman bill.hoff...@kitware.com: OK, so you depend on gmake features. Indeed. Some of the recent gmake features are really nifty and make it quite powerful. This might be an interesting thing to try with CMake some day. To generate a makefile that does not have recursion, but depends on gmake as the make processor. I will put that on the todo list. That sounds interesting indeed -- and from a bootstrapping point of view with gmake being plain C and thus very portable, it should be available on pretty much any platform (or at least on any CMake platform as CMake has higher requirements being C++). Right now CMake supports generic make. I would not be against a gmake only makefile generator being added to CMake. It would be an interesting experiment to see how this type of makefile compares for large and small projects. If you do, please have a look at the stuff we are currently doing with GNU make -- you will see that it might be possible to keep a lot of the abstractions made by CMake visible in the generated files, if one uses a small generic runtime library in GNU make. Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] SfxItemSet assumptions and assertions
Am Tue, 15 Jun 2010 09:04:45 +0200 schrieb Mathias Bauer nospamfor...@gmx.de: So this is code broken (the code in the ItemSet, not yours). I would argue that both code is broken, because as is the ItemSet has no well-defined contract to design against. Of course, Malte is no more guilty than anybody else as the only alternative is not using the broken ItemSet -- which I assume was not an option. If some code in SfxItemSet just checks for SfxVoidItems to decide whether it is a disabled item, while other code just checks for ID == 0, the problem is already there. It's also an unnecessary complexity to require the check of two attributes (type *and* ID). The next interesting question is what should happen if items derived from SfxVoidItems are used ... So perhaps coding disabled as SfxVoidItem is a severe design flaw. Yes, it is. So it would be better if disabling (and checking for disabed state) should be possible only by using explicit methods from SfxItemSet. If the implementation requires to code that by storing a special item, this item should be a private class in SfxItemSet so that it can't be used outside. The problem with that approach is that it requires a non-trivial amount of work. :-( Well, the implementation in new_itemsets only checks for the which id being 0 and never checks for the type being an SfxVoidItem (outside assertions). So an disabled item is consistently defined as any item returning an which id of 0 in the new itemset implementation. Now the interesting part is finding the clients of the itemset that rely on void items being interpreted as disabled by the itemset and fixing those Best Regards, Bjoern - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
Re: [dev] Re: BigPointerArray, SvPointerArray vs STL containers
On 06/15/2010 02:55 AM, Mathias Bauer wrote: On 14.06.2010 12:01, Caolán McNamara wrote: A code replacement like this creates the question what shall be the goal: - reduce memory footprint - improve performance - remove code duplication - improve code quality My primary interest is in code quality. I am sure you are aware of the few people with large documents that cause OOo to crash because of the limitation in array size. That said, if there is noticeable degradation in the memory footprint or performance then the other 99% of the users may be upset. If you want to see first hand what happens, close all other documents, then load AndrewMacro.odt and then close it. Boom! -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt My Book: http://www.hentzenwerke.com/catalog/oome.htm Info: http://www.pitonyak.org/oo.php See Also: http://documentation.openoffice.org/HOW_TO/index.html - To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
[dev] about oov build
hello, fedora12 yum install openoffice in my computer no problem But when i build the Ooo with the latest hg version i use the rpm -iv openoffice.org-*rpm in the folder instsetoo_native/ unxlngi6.pro/OpenOffice/rpm/install/en-US then i run the /opt/openoffice.org3/prgrams/swriter, it shows Missing vcl resource. This indicates that files vital to localization are missing. You might have a corrupt installation. Is this because i didn;t install the destop-intergration ? Or missing other modules? Thanks, i follow this page to install http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Linux
