[
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
>