Re: [wtp-dev] Question on AST creation for decoration-like jobs

[Victor Rubezhny <vrubezhny@xxxxxxxxxx>]

On 03/31/2014 09:19 AM, Mickael Istria wrote:

On 03/28/2014 07:23 PM, Victor Rubezhny wrote:

What is the point of resolving bindings each time we need to create an AST when reconcile? (It happens for almost each character typed in by a user or the selection is changed in the editor).

Could it be implemented that way to save heap space? Did you try to measure memory usage with lazy resolution vs full parsing?
If it is the reason, then it seems to me that memory isn't much of a end-user problem nowadays and that as long as it doesn't cause OutOfMemory to users, it's probably worth increasing the memory usage to improve reactivity and speed.

My point is that the resolution is not used at all in some places (the only AST itself required), but it happens for all of those places. But if we don't use the resolution result, then why we're doing it (and wasting the CPU resources and time while resolving)? You can try the example file, that I've attached as an example to my previous message, and see how slow is the selection and overall editor reaction on user actions (selection, moving cursor around, typing, displaying the hovers and so on).

And yes the exceptions happen, but the OutOfMemory is not a problem for JSDT resolution. The main problem here is StackOverflowError (there are the issues in BugZilla, as well as I have an example that reproduces the issue). The resolution algorithm is made using the recursion pretty wide (even if it's not required). This doesn't require too much memory, while the program stack is not too big to suit some cases (and sometimes those cases aren't synthetic, but the real working _javascript_ libraries).

I'm getting the AST produced almost 8 times faster and no more StackOverflowErrors in "Semantic Highlighting Job", "Requesting _javascript_ AST from selection" and "Decoration Calculation" Jobs.

That sounds like a great result!

This is the result of different issues:

- see https://bugs.eclipse.org/bugs/show_bug.cgi?id=431547 - too many vars is declared within the same var keyword - pretty seldom case, but some minified libraries use such approach. As well, this is a result of extensive use of recursion + bug in traverse algorithm.
- the wide use of recursion. Event when we're able not to use it. Yeah, the recursion is the great invention, but stack is limited!
- We don't need the result of resolution (for example for some decoration threads) but still doing it. The resolution is slow.

For most _javascript_s (not too long) it cannot be eye-measured, but this is really important for large scripts.

/Victor

--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev