[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] CPreprocessor
|
The joke was back then was that Java method calls are slow, we need to get
rid of them all, i.e. rewrite in C ;)
As I stated on the bug, if you want to try and re-architect something, do
what Markus did. Implement it to the side with a switch to turn on. Test to
make sure all the JUnits pass. Test to make sure performance on large
projects isn't slower. If that all works out, make yours the default and
after a while, if there are no further regressions are found, remove the old
one.
And Markus's experience further shows that we have a heck of a time figuring
out what impacts performance. It's really hard to figure out ahead of time
and the only way to make sure is to try it out.
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 Mike Kucera
> Sent: Thursday, November 15, 2007 1:55 PM
> To: CDT General developers list.
> Cc: CDT General developers list.; cdt-dev-bounces@xxxxxxxxxxx
> Subject: 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
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
