Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Parallelization of C/C++ indexer: SEVERE PERFORMANCE ISSUES

Hi CDT folks.

Would you please have a look into https://bugs.eclipse.org/bugs/show_bug.cgi?id=351659
The longer I try, there are more and more severe performance issues in CDT indexer, that need to be solved.

Thanks + kind regards,
Volker


-----Ursprüngliche Nachricht-----
Von: cdt-dev-request@xxxxxxxxxxx
Gesendet: 19.07.2011 21:21:37
An: cdt-dev@xxxxxxxxxxx
Betreff: cdt-dev Digest, Vol 77, Issue 85

Send cdt-dev mailing list submissions to
cdt-dev@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
or, via email, send a message with subject or body 'help' to
cdt-dev-request@xxxxxxxxxxx

You can reach the person managing the list at
cdt-dev-owner@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdt-dev digest..."


Today's Topics:

1. Re: Language extension driven by compiler inputType
(Schaefer, Doug)


----------------------------------------------------------------------

Message: 1
Date: Tue, 19 Jul 2011 19:21:31 +0000
From: "Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Subject: Re: [cdt-dev] Language extension driven by compiler inputType
Message-ID:
<B3FDFD9D87957C4B8B5F6E8C690DC3F00E4BF802@xxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"

I'll have to see how things behave when you don't have a toolchain defined. But this is all using cdt.core functionality.

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris Recoskie
Sent: Tuesday, July 19, 2011 1:13 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Language extension driven by compiler inputType


If you want to hook it up so the build system feeds settings into the core, I'm totally fine with that. I think it's important to leave it though so that the the core controls the settings and can do it without build, or that it can override the build settings if required.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto

[Inactive hide details for "Schaefer, Doug" ---07/19/2011 12:25:02 PM---To finish my thought, ICConfigurationDescription has a g]"Schaefer, Doug" ---07/19/2011 12:25:02 PM---To finish my thought, ICConfigurationDescription has a getLanguageSettingForFile() method that retur

From:


"Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx<mailto:Doug.Schaefer@xxxxxxxxxxxxx>>


To:


"CDT General developers list." <cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>>


Date:


07/19/2011 12:25 PM


Subject:


Re: [cdt-dev] Language extension driven by compiler inputType


Sent by:


cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx>

________________________________



To finish my thought, ICConfigurationDescription has a getLanguageSettingForFile() method that returns a ICLanguageSetting which has a getLanguageId() method. The LanguageMappingResolve has the ICConfigurationDescription.

I'll produce something on github so you can look and try my attempt at this. I'll do the manual method for now though so this will have to wait until I'm back from vacation in August.

From: cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schaefer, Doug
Sent: Tuesday, July 19, 2011 11:30 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Language extension driven by compiler inputType

Sorry Chris, I'm still plowing through e-mails chronologically.

I think we can accommodate both. There's already a laundry list of places the LanguageManager looks to figure out the language for a file. I just want to add in the hook to check the build system probably just before settling for the default.

:D

From: cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris Recoskie
Sent: Tuesday, July 19, 2011 10:34 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Language extension driven by compiler inputType

Part of the rationale at the time was that you needed to be able to configure languages for the parser, even if you weren't using the CDT build system. Plus, maybe you'd want to override what the toolchain was specifying anyway.

At the time as well the new-fangled CDT build model was, well, new, and no one understood how it worked, or knew for sure if it was even going to go into CDT yet, so the choice was made to keep it all decoupled.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto

[Inactive hide details for "Schaefer, Doug" ---07/19/2011 10:11:23 AM---Good point re the scanner info. It probably makes the mo]"Schaefer, Doug" ---07/19/2011 10:11:23 AM---Good point re the scanner info. It probably makes the most sense to hook up getLanguage to the build

From:


"Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx<mailto:Doug.Schaefer@xxxxxxxxxxxxx>>


To:


"CDT General developers list." <cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>>


Date:


07/19/2011 10:11 AM


Subject:


Re: [cdt-dev] Language extension driven by compiler inputType


Sent by:


cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx>

________________________________




Good point re the scanner info. It probably makes the most sense to hook up getLanguage to the build system using a similar method as getScannerInfo.

I'm assuming the ids mean the same in build as in core. That's what I would have done. I should go back through time and see if the build side was ever hooked up.

Doug.

From: cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schorn, Markus
Sent: Tuesday, July 19, 2011 2:51 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Language extension driven by compiler inputType

We have public API to determine the language of a translation-unit, what you get from there can be configured via workspace/project/folder and file settings:
ITranslationUnit.getLanguage().
The API is reasonable, nevertheless, there may be a disconnect with the build-system and there may be a need to change the implementation. I am not sure whether the build-system uses the same language ids and whether they have the same meaning?

The scanner configuration (IExtendedScannerInfo) represents the input to the preprocessor, it should not carry other information, such as the language id.
Markus.


From: cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Schaefer, Doug
Sent: Tuesday, July 19, 2011 04:51
To: CDT General developers list.
Subject: Re: [cdt-dev] Language extension driven by compiler inputType
Importance: Low

I don't think that was the design intent. The idea is that a given file in the active configuration has a language and a lot of work is done in MBS to figure out which inputType to use to figure that out. Stick a breakpoint in InputType.getLanguageId() to see it in action.

Digging into things a little (lot) deeper, I can see where CLanguageSettingCache actually has the languageId with it. The DescriptionScannerInfoProvider has access to it when creating the ExtendedScannerInfo which gets passed up to the parser in TranslationUnit.getAST() but it doesn't pass it along. Funny enough a couple of lines later it tries to figure out the ILanguage, so close, so far.

Maybe the right answer is to add the language to the ExtendedScannerInfo so that TranslationUnit can get at it. Anyone have an opinion on that?

Doug.


From: cdt-dev-bounces@xxxxxxxxxxx<mailto:cdt-dev-bounces@xxxxxxxxxxx> [mailto:cdt-dev-bounces@xxxxxxxxxxx]<mailto:%5Bmailto:cdt-dev-bounces@xxxxxxxxxxx%5D> On Behalf Of Andrew Gvozdev
Sent: Monday, July 18, 2011 10:38 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Language extension driven by compiler inputType

You can inquire IConfiguration->ITool->IInputType inside MBS but I don't think you can get language to core that way. That would be ambiguous anyway as there could be several tools in toolchain and you can't access the tools from core.
You probably need to introduce a new content type and find the language from file extension via content type. I looked briefly and it seems that CConfigurationDescription.getLanguageSettingForFile() works that way.

Andrew
On Mon, Jul 18, 2011 at 10:02 PM, Schaefer, Doug <Doug.Schaefer@xxxxxxxxxxxxx<mailto:Doug.Schaefer@xxxxxxxxxxxxx>> wrote:
Hey gang,

I'm not sure how many people have done this, but I'm hoping someone out there can help. I'm writing a build integration for a new compiler (new to CDT at least). It supports a few language extensions. Now I thought I'd try by setting the languageId attribute in the inputType element of my compiler and figured that information should somehow get to the scanner. But no luck.

As far as I can tell, the gcc languages work because their the default, not because of the languageId setting in the build definitions. Has someone got this to work and can point me where I'm missing something.

Thanks,
Doug.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/cdt-dev/attachments/20110719/09c85109/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: image001.gif
URL: <https://dev.eclipse.org/mailman/private/cdt-dev/attachments/20110719/09c85109/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 168 bytes
Desc: image003.png
URL: <https://dev.eclipse.org/mailman/private/cdt-dev/attachments/20110719/09c85109/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 166 bytes
Desc: image004.png
URL: <https://dev.eclipse.org/mailman/private/cdt-dev/attachments/20110719/09c85109/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 168 bytes
Desc: image005.png
URL: <https://dev.eclipse.org/mailman/private/cdt-dev/attachments/20110719/09c85109/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 166 bytes
Desc: image006.png
URL: <https://dev.eclipse.org/mailman/private/cdt-dev/attachments/20110719/09c85109/attachment-0003.png>

------------------------------

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


End of cdt-dev Digest, Vol 77, Issue 85
***************************************



Back to the top