Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Parallelization of C/C++ indexer: SEVERE PERFORMANCE ISSUES 
Such a header will cause problems, 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=197989

Markus.

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of kesselhaus
Sent: Wednesday, July 27, 2011 01:10
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Parallelization of C/C++ indexer: SEVERE PERFORMANCE ISSUES
Importance: Low

Hi folks,

Just skimmed over the first replies on that bugzilla entr.

By Markus Schorn:
"When parsing a translation unit we reuse information about headers that have been parsed before. Therefore a simple parallelization is not possible here."

a) Is this maybe the problem, that parsing an over an OSEK header, there are so much missing definitions?
And is there a way to get around that limitation then? (We surely can not change that 3rd Party OSEK code for that) The source code generated by the OIL tool uses a multistage inclusion of OSEK, like:

foo.c
----------------------------------------------------------------------------
#define _PRE_TCB_INCLUSION
#include "tcb.h"

/*
stuff
stuff
stuff
*/

#define _POST_TCB_INCLUSION
#include "tcb.h"

/*
stuff
stuff
stuff
*/
------------------------------------------------------------------
while tcb.h is like:

#ifndef _PRE_TCB_INCLUSION
#define _PRE_TCB_INCLUSION

/* define/declare etc 1st step */

#enfif // _PRE_TCB_INCLUSION

#ifndef _POST_TCB_INCLUSION
#define _POST_TCB_INCLUSION

/* define/declare 2nd step */

#endif // _POST_TCB_INCLUSION
--------------------------------------------------------------------


b) Since you already use an Index(er), can you provide a code search option to search any code, not just the active code?
The platform provided search is so damn slow. Or is it just my laptop at work? ;)

Regards,
kessel


Am 19.07.2011 21:42, schrieb Volker Diesel:
> 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@
> eclipse.org%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/20110
> 719/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/20110
> 719/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/20110
> 719/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/20110
> 719/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/20110
> 719/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/20110
> 719/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
> ***************************************
>
> _______________________________________________
> 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

Back to the top