Loading the bug document in fdo#76260 - we do 8.7 million calls to create OOXMLPropertySetImpl - the vast majority of the cost of that structure is the heap allocation and copying of the debugging member:
We burn 6bn cycles doing just this (per element I guess).
That type is only useful for debugging.
I'll fix the performance issue in this local case - but we shouldn't be exposing this virtual method when it is not used widely I guess.
It'd be nice to have this compiled out of the relevant writerfilter::Reference etc. vtables and/or removed completely.
Its unclear to me what good it provides that some RTTI typeid(*ptr).name() can give us...
Thoughts miklos ? =)
Hopefully we can leave this as an easy hack though ...
I've pushed the speedup part; so dropping that from the title for now - even though not doing this OUString thrash would save quite some time really.
adding LibreOffice developer list as CC to unresolved Writer EasyHacks for better visibility.
see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Migrating Whiteboard tags to Keywords: (easyHack, difficultyBeginner, skillCpp, topicCleanup)
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC)
Hi! I would like to work on this issue. I have found some "writerfilter::Reference" but couldn't find anything sort of "OOXMLPropertySetImpl::OOXMLPropertySetImpl()
>It'd be nice to have this compiled out of the relevant writerfilter::Reference
>etc. vtables and/or removed completely.
Could you please brief about it.
Interesting; this task got simpler, and the class got renamed:
class OOXMLPropertySet : public writerfilter::Reference<Properties>
Can we remove the maType member ? which is now an OUString (for no apparent reason) and gets intialized and deleted along with that class for no benefit at all (that I can see ;-). But needs some code-reading.
I think the only user of that name is the SW_DEBUG_WRITERFILTER=1 ./soffice.bin foo.docx code which creates a /tmp/foo.docx.DOMAINMAPPER.xml file; and sure, having the type info there manually is probably pointless. Please just test this writerfilter XML token dump when you do changes in the tokenizer (see if you break it), as that debug code has no testcase coverage.