Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [handly-dev] lazy handling of ISourceFiles

Oh, I see. Your case is pretty unique indeed, interprocess communication can be tricky. I'd hope that the general principles mentioned above still apply, though. I'm willing to help and do whatever I can on my side (without destroying others, of course :-) ), but I think we'll have to look into the specifics and metrics in order to decide on the best course of action.
Best regards,
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,

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.
Hi 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,

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,

handly-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top