'Re: Review Request: load table:table as part of a draw:frame in the'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Review Request: load table:table as part of a draw:frame in the
From:       "Thorsten Zachmann" <t.zachmann () zagge ! de>
Date:       2010-04-28 5:09:37
Message-ID: 20100428050937.9090.18155 () localhost
[Download RAW message or body]

> On 2010-04-25 09:44:54, Thomas Zander wrote:
> > Thanks for working on this :)
> > I'm just giving this a general overview, I don't know the odf loading all that \
> > well. The QPair looks very complicated to me so I gave it some thought how to \
> > make it simpler.  Hope it makes sense.
> 
> Thorsten Zachmann wrote:
> I don't think the QPair is in any way complicated but that might be a personal \
> opinion. As a QPair can be used so a QHash can be used. However for the place where \
> it is used a hash which provides a fast lookup is not needed. I would say the list \
> should be faster here as the adding and iterating over the list are faster than for \
> a hash and these are the only used operations. 
> Thomas Zander wrote:
> Inserting into a hash is indeed slightly more expensive. This is why I suggested to \
> use a pointer as the key. This makes calculating the hash-key very cheap. But I see \
> your point; you can also use a QMap if the speed of insertion is relevant. I \
> personally doubt we'll add more than 2 keys into that (has)map so I don't think it \
> matters all that much. 
> Using a QPair is a couple more lines of code for every insert or lookup, I don't \
> really see the need for that when you can avoid it using just a different container \
> that already has two values. Does that make sense?

I used a QPair fo now. It does not add more lines just some more chars in the line \
for the iterator. I done some benchmarking and found out that a list with a pair in \
it is faster the using a map or a hash. Also as it is basically a list I have gone \
for that for now. However I like the idea of Boudewijn to use a struct that makes \
more clear what the members are used for. However that means more code as we need to \
add a struct that basically does the same as a QPair.

> On 2010-04-25 09:44:54, Thomas Zander wrote:
> > trunk/koffice/libs/flake/KoShapeFactoryBase.cpp, line 96
> > <http://reviewboard.kde.org/r/3805/diff/2/?file=24505#file24505line96>
> > 
> > Now we no longer return a odfNameSpace() as a QString I'd like to suggest that \
> > the namespace is kept as a const char *. The advantage there is that we can use \
> > the pointers from KoXmlNS and thus only do pointer comparison for namespaces.  \
> > Which means that we avoid converting to utf16 (QString native) on call to \
> > setOdfElementNames and avoid a string compare. That should make a significant \
> > impact in startup time too :) 
> > This, together with the previous suggestion, would make the elements stored like;
> > QHash<char*, QStringList>
> 
> Thorsten Zachmann wrote:
> There was always a QString used for the namespace
> 
> -QString KoShapeFactoryBase::odfNameSpace() const                                   \
>  
> so this patch doesn't change anything in this regard.
> 
> It is needed as a QString in the registry as there we have a QString we need to \
> compare it too. So it makes sense to do the conversion only once. 
> Thomas Zander wrote:
> I completely agree it was always a QString, didn't mean to imply anything else or \
> that you broke something. I'm just looking at this from the point of view that with \
> the new data structure you introduced the thing may need an extra look as it does \
> look rather imposing with nested templates now. In the registry we do too many \
> implicit conversions which really makes things slower than they need be. So, yes, \
> some extra code is needed in the registry (specifically \
> KoShapeRegistry::Private::createShapeInternal) to make this use the char*, but it \
> does certainly look like its worth it. To be clear; if you see a
> e.namespaceURI() == KoXmlNS::draw
> the right parameter is a char*, so this causes a conversion of the char* to QString \
> (utf16) and then a string compare. This is done quite often, so thats my point. It \
> would be much cheaper to replace all this with simple pointer compares. 
> Anyway, I hope you see my point and think it makes sense to make things even \
> better.  I won't insist on anything, I just wanted to give you an idea for \
> improvement.

Unfortunately the left parameter in
e.namespaceURI() == KoXmlNS::draw
is a QString so the KoXmlNS::draw needs to be converted to a QString to compare the \
string. Even if we would also have a char * for the namespaceURI we would need to \
compare the content and not only the pointers.

I done some benchmarking with 

QString == char * and QString == QString and they is no difference in speed and we \
get over 10000000 comparisons in a second. 

- Thorsten

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3805/#review5215
-----------------------------------------------------------

On 2010-04-25 06:55:45, Thorsten Zachmann wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3805/
> -----------------------------------------------------------
> 
> (Updated 2010-04-25 06:55:45)
> 
> 
> Review request for KOffice.
> 
> 
> Summary
> -------
> 
> Make it possible to load a table:table inside a draw:frame. To make this possible \
> it is needed to extend KoShapeFactory and KoShapeRegistry that multiple namespaces \
> -> tag's can be supported by one shape. 
> 
> This addresses bug 231680.
> https://bugs.kde.org/show_bug.cgi?id=231680
> 
> 
> Diffs
> -----
> 
> trunk/koffice/libs/flake/KoShapeFactoryBase.h 1118236 
> trunk/koffice/libs/flake/KoShapeFactoryBase.cpp 1118236 
> trunk/koffice/libs/flake/KoShapeRegistry.cpp 1118236 
> trunk/koffice/libs/flake/tests/TestKoShapeFactory.cpp 1118236 
> trunk/koffice/libs/kotext/opendocument/KoTextLoader.cpp 1118236 
> trunk/koffice/plugins/textshape/TextShape.h 1118236 
> trunk/koffice/plugins/textshape/TextShape.cpp 1118236 
> trunk/koffice/plugins/textshape/TextShapeFactory.cpp 1118236 
> 
> Diff: http://reviewboard.kde.org/r/3805/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Thorsten
> 
> 

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread] 