[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] CPreprocessor
|
Doug, I believe you and agree with what you're saying. Using char[]s with
direct array access is definitely more efficient that using Strings with
charAt(). Especially since we need to access every element of the source
buffer, so that would be a very high number of calls to String methods.
My first point was that this proves that char[]s are better than Strings
for our preprocessor/parser, not that method calls are the enemy in
general. (I think its dangerous to think that way. Methods should be small
and to the point. Thinking of method calls as bad could lead to "premature
inlining" which results in code that's harder to read.)
My second point was that you can still do the char[] optimization with a
token-based preprocessor. With the new approach you get the best of both
worlds, that's why the new preprocessor has a more modular design yet still
performs as fast. I though you were using the char[] thing as an argument
against the new preprocessor design, but please correct me if I was wrong.
Mike Kucera
Software Developer
IBM CDT Team, Toronto
mkucera@xxxxxxxxxx
Doug Schaefer
<DSchaefer@xxxxxx
m> To
Sent by: "CDT General developers list."
cdt-dev-bounces@e <cdt-dev@xxxxxxxxxxx>
clipse.org cc
Subject
11/15/2007 11:22 RE: [cdt-dev] CPreprocessor
AM
Please respond to
"CDT General
developers list."
<cdt-dev@eclipse.
org>
I swear it's because you have less method calls. I know you guys don't
believe me :)
And I've ran into this before. When I switch from Strings to char[]s in the
scanner, I got a savings of around 25%. But you'll never find a profiling
tool that'll tell you that you were 25% of your time in String methods.
If it's not the expense of Java method calls, then you are running into
caching or swapping issues. My Firefox test was done on a 512MB RAM
machine.
If your fixes enabled the parsing to run in less physical memory, that
could
explain why I got a bigger improvement.
Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, http://cdtdoug.blogspot.com
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Schorn, Markus
> Sent: Thursday, November 15, 2007 8:23 AM
> To: CDT General developers list.
> Cc: cdt-dev-bounces@xxxxxxxxxxx
> Subject: RE: [cdt-dev] CPreprocessor
>
> Hmm, this becomes confusing. I guess my setup is different (firefox on
> windows using cygwin).
>
> Without having a proof, I claim that the new location map is faster
> than the old one, because it is simpler. I never though that it could
> make
> up for the performance loss in the lexer, though.
>
> I also see a slight improvement in the problem percentage (firefox: 6.83
> -> 6.75), which may influence the performance (in either way).
>
> All together, it looks like we can digest the 25% performance drop on
> the lexer side and index firefox in less than 15min, that's what I am
> happy about.
>
> Here are my firefox numbers:
>
> DOMScanner:
> PDOMFastIndexerTask firefox-2.0 (2521 sources, 4108 headers)
> PDOMFastIndexerTask Options: parseAllFiles=false,skipReferences=false,
> skipTypeReferences=true.
> PDOMFastIndexerTask Timings: 668000 total, 210188 parser, 293708
> resolution, 117220 index update.
> PDOMFastIndexerTask Errors: 0 unresolved includes, 0 unexpected errors.
> PDOMFastIndexerTask Result: 579947 declarations, 1497415 references,
> 152186(6,83%) problems.
> PDOMFastIndexerTask Cache[30mb]: 834387236 hits, 121874(0,0146%) misses.
>
>
> CPreprocessor:
> PDOMFastIndexerTask firefox-2.0 (2521 sources, 4108 headers)
> PDOMFastIndexerTask Options: parseAllFiles=false,skipReferences=false,
> skipTypeReferences=true.
> PDOMFastIndexerTask Timings: 667513 total, 215723 parser, 304567
> resolution, 125964 index update.
> PDOMFastIndexerTask Errors: 0 unresolved includes, 0 unexpected errors.
> PDOMFastIndexerTask Result: 603145 declarations, 1497095 references,
> 152045(6,75%) problems.
> PDOMFastIndexerTask Cache[30mb]: 918390081 hits, 132025(0,0144%) misses.
>
> Markus.
>
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Mike Kucera
> > Sent: Mittwoch, 14. November 2007 20:07
> > To: CDT General developers list.
> > Cc: CDT General developers list.; cdt-dev-bounces@xxxxxxxxxxx
> > Subject: RE: [cdt-dev] CPreprocessor
> > Importance: Low
> >
> > Those are great numbers.
> >
> > Markus, I'm curious to know where you think the performance
> > gain is coming
> > from. Is it the new location map?
> >
> >
> > Mike Kucera
> > Software Developer
> > IBM CDT Team, Toronto
> > mkucera@xxxxxxxxxx
> >
> >
> >
> >
> >
> > Doug Schaefer
> >
> > <DSchaefer@xxxxxx
> >
> > m>
> > To
> > Sent by: "CDT General
> > developers list."
> > cdt-dev-bounces@e <cdt-dev@xxxxxxxxxxx>
> >
> > clipse.org
> > cc
> >
> >
> >
> > Subject
> > 11/14/2007 01:39 RE: [cdt-dev]
> > CPreprocessor
> > PM
> >
> >
> >
> >
> >
> > Please respond to
> >
> > "CDT General
> >
> > developers list."
> >
> > <cdt-dev@eclipse.
> >
> > org>
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > I don't know. I'm showing a 10-20% improvement with my Firefox tests.
> >
> > Great work Markus, thanks!
> >
> > Doug Schaefer, QNX Software Systems
> > Eclipse CDT Project Lead, http://cdtdoug.blogspot.com
> >
> >
> > > -----Original Message-----
> > > From: cdt-dev-bounces@xxxxxxxxxxx
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> > > Behalf Of Schorn, Markus
> > > Sent: Wednesday, November 14, 2007 5:03 AM
> > > To: CDT General developers list.
> > > Subject: RE: [cdt-dev] CPreprocessor
> > >
> > > I have rerun the tests over night and the result is less
> > spectacular,
> > > you can expect improvements from 0% to 4%. Probably the
> > first results
> > > were influenced by some other load on my machine, so I need to reset
> > > expectations:
> > >
> > > In detail ACE -6%, TAO -0%, Linux Kernel -5%, Firefox -0%.
> > > I am happy with the numbers, anyways. I am changing CDT to use
> > > CPreprocessor.
> > > I'll keep Scanner2 around until the end of the year, but plan on
> > > removing it,
> > > to get started on stuff that depends on the preprocessor.
> > > Markus.
> > >
> > > > -----Original Message-----
> > > > From: cdt-dev-bounces@xxxxxxxxxxx
> > > > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schorn, Markus
> > > > Sent: Dienstag, 13. November 2007 16:13
> > > > To: CDT General developers list.
> > > > Subject: [cdt-dev] CPreprocessor
> > > > Importance: Low
> > > >
> > > > Hi,
> > > > the performance tests for the indexer using the CPreprocessor went
> > > > really good, I see an overall performance improvement of
> > 5-10% (tested
> > > > with ACE, TAO, Linux Kernel and Firefox).
> > > >
> > > > Given that I want to make the CPreprocessor the default
> > rather sooner
> > > > than later and support Scanner2 with -Dscanner=Scanner2
> > for a while.
> > > > Does anyone object to that?
> > > > Markus.
> > > >
> > > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=205272
> > > > _______________________________________________
> > > > cdt-dev mailing list
> > > > cdt-dev@xxxxxxxxxxx
> > > > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > > >
> > > _______________________________________________
> > > cdt-dev mailing list
> > > cdt-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
