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 javascripts (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 <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
_______________________________________________
wtp-dev mailing list
wtp-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/wtp-dev