Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Firefox Fast Index Times

isStatic is related since it does a resolveAllDeclarations (for some reason) which does a whole bunch of PDOM searches as well.

 

Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, Tools PMC Member


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Monday, November 20, 2006 3:22 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] Firefox Fast Index Times

 

After further analysis, bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=165213 has been raised on one of the main culprits of the performance degradation.

 

I also saw big numbers on CPPFunction.isStatic(), and Markus saw them too, I’ll need to investigate more on that one.

 

Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, Tools PMC Member


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Monday, November 20, 2006 1:49 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] Firefox Fast Index Times

 

Unfortunately, no. J

 

I started using the TPTP profiler to test out our old parser performance test we affectionally cursed, the Trilogy. The Trilogy is a simple file that looks a lot like this:

 

#include <stdio.h>
#include <windows.h>

#include <iostream>

 

int main() { return 0; }

 

We used to run it with cygwin with the mingw package installed (to get windows.h). I am now doing it with the Windows Build integration.

 

With my first run, I am seeing FindEquivalentBinding visitor taking 2/3’s of the time. This visitor is new and searches the PDOM very often. I can see how, as the PDOM gets bigger, this function takes a bit longer since the searches have a bigger B-Tree to deal with (but theoretically, the incremental time should be minimal). But this functionality is new in HEAD and should be a good place to start.

 

Cheers,

Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, Tools PMC Member


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sergey Prigogin
Sent: Monday, November 20, 2006 1:16 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Firefox Fast Index Times

 

I guess the difference in indexing time reflects the improvement in index coverage :-).

Indexing speed seems to be highly nonlinear. Towards the end of my 3K files code base, parsing of some files took several minutes a piece instead of a subsecond time in the beginning.

-sergey

On 11/17/06, Doug Schaefer <DSchaefer@xxxxxxx> wrote:

Hey gang,

 

We've now cleared up enough exceptions to fully index Firefox 2.0 with the Fast indexer. Here are the numbers I got. The initial index is the first one after launching Eclipse (includes binary parser times, disk caching, etc.) and the reindex is from the Reindex menu item (pretty much pure indexing time). These tests were done on my 512 MB, Athon 64 2800 (very average machine) running Ubuntu Linux.

 

CDT 3.1.1

            Initial index – 12.3 minutes

            Reindex – 10.3 minutes

 

HEAD

            Initial Index – 122.2 minutes

            Reindex – 119.6 minutes

 

My heart bleeds….

 

There are still a few exceptions that I'm working on cleaning up, but I don't think they'll impact these times much.

 

I will continue to monitor these times and give you regular reports.

 

Doug Schaefer, QNX Software Systems

Eclipse CDT Project Lead, Tools PMC Member

 

 


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev

 


Back to the top