| Re: [handly-dev] lazy handling of ISourceFiles |
Thank you very much for your insights.I think that most of my issues are based on my particular implementation: the parser and linker and cross-reference datanase are (or will be) implemented outside Eclipse, in Erlang. Passing lots of data back and forth is what is expensive and difficult to synchronize. That's why I am looking at different ways of reducing the need for such communication.best regards,Vlad
On Mon, Apr 20, 2015 at 1:35 PM, Vladimir Piskarev <pisv@xxxxx> wrote:
And thinking a little bit more about it, when you are reconciling a working copy, you often need much more than its structural model. Usually, you also need a fully fleshed out AST for "smart" editor to operate on, with every parsing/resolution problem promptly discovered and reported to the user via the editor annotation model. JDT, for example, does it all at once while you are typing in the Java editor and seems to perform well enough. I think what's really important here is that most of the work should happen outside the UI thread, with proper support for cancellation.On the other hand, when we are not talking about reconciling/working copies, even "lazy" parsing might work, but I'm yet to be convinced that it would do much better than "diet" parsing of the whole source file, with regard to "performance vs. complexity" trade-off. Again, JDT doesn't do any "lazy" parsing and seems to perform well enough. That said, I remain open-minded.-VladimirHi Vlad,I think that parsing the whole file at once is important to ensure consistency with the given source snapshot, as dealing with snapshot inconsistencies can be tricky -- to say the least. IMO, partial parsing ("parse structural elements only") and/or incremental parsing ("reparse only what's changed"), not "lazy" parsing would be the correct answer. We have not observed any significant performance issues with the current design, even on source files with more than 50K LOC, with thousands of structural elements. If you still have concerns, I'm open to further discussion.Best regards,VladimirHi!If the source files are large and if the language allows to easily identify top level constructs that can be parsed individually, it would be meaningful and useful to not parse the whole file at once, but do it lazily when needed, just like for projects and folders.Handly doesn't currently allow that and it wouldn't be easy to make it work (the parsing is relatively doable, but I don't think the reconciling and working copy stuff will play nice with such a change). My question is whether you think it is worth investigating further.best regards,Vlad
_______________________________________________
handly-dev mailing list
handly-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/handly-dev