Why are empty Indexed*Identifier checked for ref counting?

Milian Wolff mail at milianw.de
Wed May 5 10:58:57 UTC 2010


Milian Wolff, 05.05.2010:
> Hey all, esp. David:
> 
> Why are IndexedQualifiedIdentifier and IndexedIdentifier checking
> shouldDoReferenceCounting when they are empty? I.e. their ctors without any
> arguments.
> 
> And actually I'd be interested in why we need something like
> emptyConstantIdentifierPrivateIndex() at all. It uses e.g.:
> 
> static uint index =
> identifierRepository->index(DynamicIdentifierPrivate()); if (index == 0)
>   ...
> 
> the doc comment of ->index tells us, that it can _never_ be 0, hence either
> the conditional is obsolete or the comment is wrong.
> 
> And shouldn't/couldn't we use m_index(0) for the empty case, just like with
> IndexedStrings? That would also speed up KDevelop, since right now e.g. the
> IndexedQualifiedIdentifier in the CodeModel always goes through this no
> matter what. The question is of course whether it should do
> duchainrefcounting at that point or not ;-)
> 
> A few more doccomments would certainly be welcome!

Just to note: I enabled the debug output in identifier.cpp and extended it to 
also count the number of operations on empty Indexed* classes. Turns up than 
more than 50% of the operations are on empty Indexed* when starting with a 
blank duchain. When updating a chain without updates, 100% of the indexed* 
seem to be empty.

So it would certainly be interesting to speed these cases up.

Oh and another thing: shouldDoDUChainReferenceCounting triggers true for the 
empty indexed* when somewhere inside the doMoreCleanup callchain. Not before. 
Is this the correct behavior? I.e. is the refcounting only relevant when 
saving to disk?
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100505/9c5cd94e/attachment.sig>


More information about the KDevelop-devel mailing list