[antlr-interest] Serious doubts on usage of incremental parsinginides

Prashant Deva prashant.deva at gmail.com
Mon Apr 25 05:35:54 PDT 2005


Part 3  of my reply ...

Also notice that i am not saying that the incremental parser slows the
stuff down.
No, its updating all the other stuff attached to the parser that slows
everything down.

Note that things like a tree view, if you are gonna update on every
keystroke, it will flash like hell.
Will be almost like a blinking tree ;)

PRASHANT

On 4/25/05, Prashant Deva <prashant.deva at gmail.com> wrote:
> Part 2 of my reply .....
> 
> >Unless
> > you have a very slow machine or very low RAM causing swapping, this should
>  > be pretty much unnoticeable.
> 
> I have a 2.4 ghz processor and 512 mb ram and believe me my
> incremental parser is FAST. all my tests are standalone swt apps so
> they take like 6 mb in mem max. But still i notice sluggishness if i
> run it on every keystroke.
> 
> Also eclipse has insanely complex code in ALL its ui elements to
> handle those deltas.
> Look at the outline view for example. They had to almost completly
> reimplement that tree view to make it NOT work on domain objects.
> 
> Same goes for stuff like folding and semantic highlighting.
> PRASHANT
> 
> 
> On 4/25/05, Prashant Deva <prashant.deva at gmail.com> wrote:
> > Scott,
> > >
> > > AFAICS, the user can only be editing one thing at a time, so there's really
> > > only one model to update (no matter how many views on that model). Unless
> > > you have a very slow machine or very low RAM causing swapping, this should
> > > be pretty much unnoticeable.
> >
> > Again you are not getting me.
> > Lets say we have the following which needs to be updated on every keystroke-
> > 1.) Tree View
> > 2.) Search results view
> > 3.) 3d (hell, lets say OpenGL) dig
> > 4.) Editor highlighting
> > 5.) Symbol table entries
> > 6.) Auto indentation
> > 7.) Folding structure
> >
> > Now if you are going to update all these things on every single
> > keystoke  ,then the editor is gonna seem real slow.
> >
> > And mind you if you don't run the parser on every keystroke, then you
> > are limiting its power to as good as a batch parser.
> > Hell, a batch parser also takes jsut arnd 30 ms to parse a 10,0000
> > line file, and we are going to be updating after say 500ms anyway, so
> > what diff does it make whether we run a batch parser in between or an
> > incremental parser.
> >
> > As you are talking so much about eclipse, well look at the source.
> > they run a FULL parse each time, and just get the deltas of the diff
> > between 2 asts.
> > They DONT have an incremental parser.
> >
> > Take a look at 'JavaSourceViewerConfiguration', in the getReconciler()
> > method. Hell even the reconciler there is not incremental. There
> > stands no question of incremental parsing.
> >
> > They just do incremental compilation, for which they anyway have to
> > parse the full file, and as its done only each time you save, the
> > little slowness does not get noticed.
> >
> > So here is my problem stated once again -
> > You can't run an incremental parser on every keystroke cause no matter
> > how fast the parser is, the amount of 'other' stuff to update will
> > slow the editor.
> > If you can't run the parser on each keystroke, the incremental parser
> > is as good as a batch parser cause the time interval you are gonna run
> > it in, you can run the batch parser 10 times in it anyway.
> >
> > So what's the use of an incremental parser.
> >
> > Also i was looking at this blog of the guy who handles intellisense in
> > visual studio. even they don't run their parser on each keystroke,
> > cause it will be too slow.
> > And eclipse is not fast! its just that parsing is not that slow after all ;)
> >
> > PRASHANT
> >
> >
> > On 4/25/05, Scott Stanchfield <scott at javadude.com> wrote:
> > > Ahhh... I took "incremental parsing" for "incremental compilation".
> > >
> > > Never mind ;)
> > >
> > > AFAICS, the user can only be editing one thing at a time, so there's really
> > > only one model to update (no matter how many views on that model). Unless
> > > you have a very slow machine or very low RAM causing swapping, this should
> > > be pretty much unnoticeable.
> > >
> > > I guess I'll come back to eclipse anyway. I've never noticed it stopping me
> > > just because it's updating its ast. Occasionally I'll have to wait a few
> > > seconds for a large build (due to some validation weirdness in the
> > > webtools), but even that's minimal.
> > >
> > > I'm not sure if eclipse is totally rebuilding the ast each time or not (it
> > > may be). I'm working on a plugin that filters trivial get/set methods and
> > > displays an editable table of bean properties (which is why I want the ANTLR
> > > tree support to be more flexible), and I had it rebuild the ast each time
> > > and it wasn't noticeable to me. (In other words, the ast build was getting
> > > called at least twice per refresh; once by eclipse, once by me. However,
> > > eclipse may be caching it and detecting changes so it can simply return it).
> > >
> > > Later,
> > > -- Scott
> > >
> > >
> >
>


More information about the antlr-interest mailing list