Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] CDT performance:

+1 based on the idea.  Can't comment on the implementation yet however.

Thomas 

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Krasilnikov, Oleg
> Sent: October 24, 2005 12:17 PM
> To: CDT General developers list.
> Cc: Voronin, Mikhail; Sennikovsky, Mikhail
> Subject: RE: [cdt-dev] CDT performance: 
> 
> Hi all.
> 
> I propose a small modification for CDT performance 
> improvement in Cmodel implementation.
> 
> Currently, C/C++ source file is parsed again and again after 
> each modification in CEditor.
> 
> So, I propose:
> 
> After "documentChanged" event fires, check whether 
> modification is located in global space or inside of any 
> function body. 
> In first case, run "CReconcilingStrategy.reconcile()", as usual. 
> Else, do nothing, since these changes are not meanful for outline.
> 
> Test results on 200K file:
> Before: 230-420 ms for parsing after each typing.
> After: less than 1 ms normally. In rare cases, max 10 ms for 
> additional checks + usual parsing time.
> 
> Bug 113518 has been added to the database, it contains detail 
> description.
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=113518 
> 
> -----------------------------------
> With best regards, Oleg Krasilnikov
> Software designer, Eclipse team. 
> Intel corp.
> +7 8312 162 444 ext. 2587
> (Russia, Nizhny Novgorod)
> 
> 
>  
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Krasilnikov, Oleg
> Sent: Thursday, October 20, 2005 8:00 PM
> To: CDT General developers list.
> Cc: Voronin, Mikhail
> Subject: [cdt-dev] CDT performance 
> 
> Hi all.
> 
> Can anybody say whether the following things (related to CDT
> parformance) were discussed ?
> 
> 1. CModel optimization: currently, whole C file is parsed after each
> change in editor.
>    May be it's reasonable to re-parse changed fragment only. 
>    Problem: even if 1 char changed, whole code structure can 
> be affected
> in some cases.
>    Mean to resolve: if we are "not sure", we can re-parse whole file,
> like now. In worst case,
>    we'll have the same situation as now (additional checks seem to be
> low-weight).
> 
> 2. Store source files (expecially common includes) in some 
> "half-parsed"
> format.
>    In general, 
>      - create "mirror" directory (possibly on fastest hard 
> disc, unlike
> slow network CVS devices)
>      - for each original source file, create corresponding 
> mirror file,
> which should contain:
>          - macros definitions
>          - includes definitions
>          - token objects
>          - unresolved macros  
>          - specific records for #ifdef / #if / ... statements
>    When scanner references some source file, we can check 
> whether mirror
> file is newer
>    than original one. If so, we can use mirror file - so, no 
> need to do
> scanning again: we
>    are skipping most of scanner activity (char-by char text analyse) 
>    Disadvantage: need to write mirror file after each source change.
>    May be, it's reasonable to enable mirroring for specific 
> directories
> only (system includes,
>    which are not intended for change but referenced multiple 
> times from
> different sources).
> 
> I'm investigating these things now, but may be somebody have already
> worked with it ?
> -----------------------------------
> With best regards, Oleg Krasilnikov
> Software designer, Eclipse team. 
> Intel corp.
> +7 8312 162 444 ext. 2587 
> (Russia, Nizhny Novgorod)
> _______________________________________________
> 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