Some timing regarding ADL..

David Nolden zwabel at
Fri Nov 26 02:06:54 UTC 2010

I've tested the ADL patch on a test directory of about 110 quite long
C++ files (with quite a bit of namespace usage). You can do this using
the following command:
CLEAR_DUCHAIN_DIR=1 time duchainify -f all-declarations-and-uses

This will always completely clear the duchain cache, and rebuild it
using the given features.

Here's the timing for some different features:
simplified-visible-declarations (no type lookup, automatically used on
_huge_ projects):
visible-declarations (default project-wide processing):
all-declarations-and-uses (used for files open in the editor, or
globally during "find uses" or rename operations):
all-declarations-and-uses after merge of the ADL patch:

Normally the use-building alone, which is what ADL is a part of, takes
about 11.45s. However with the ADL patch, it becomes by 350% slower!

I have spent the whole evening fixing the problems of the patch, and
it is somewhat acceptable now. The main problem was that ADL was
triggered in much too many situations. It doesn't need to be triggered
when accessing class-members, it shouldn't be triggered when some of
the arguments are unresolved (since it's impossible to find a "viable"
function then anyway), and the whole way the duchain was used was not
very efficient.

Here's the new timing:
Use-building with full ADL takes 12.1s (12% slower than without ADL),
and when not using ADL for operators it takes 12.1s (6% slower than
without ADL).

Don't get me wrong, I think you did a very good Job finding your way
through the complex c++ duchain code. Generally, I am pretty sure that
there are ways to make this more efficient. For example, by
identifying more situations in which ADL is not required. Please try
speeding up the thing more, as I'm currently not sure whether the
remaining 12% slowdown are worth this feature.

I have pushed the changes to the repository now. @Milian:
In future, it please do a few _real_ performance tests (using
duchainify) before merging such huge changes with obvious performance
problems. This thing should have stayed in a branch for a while.

Greetings, David

More information about the KDevelop-devel mailing list