Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] OOME and performance issues in JSDT - questions for those who use...

Hi Victor,

A big +1 to have a switch to turn off some JSDT capabilities to make the JS editor usable with big files and projects. We have lots of complains about JSDT performance in our product.


On Tue, May 19, 2015 at 9:34 PM, Victor V. Rubezhny <vrubezhny@xxxxxxxxxx> wrote:
Hi All,

I'd like to ask several questions regarding  OOME while parsing/infer types issues and the overall performance...

There are pretty many related issues in bugzilla like the following:
Bug 317249 - [performance] Eclipse frequently hangs with high CPU when editing _javascript_ with lots of local declarations
Bug 323283 - [performance] Opening env.rhino.1.2.js hangs Eclipse
Bug 324299 - [performance] _javascript_ editor crashes or destabilizes Eclipse
and many others...

These issues aren't easy to fix and mostly require to have some compromise between the performance and functionality.

As such, I'd like to ask: do we need a mode/option for JSDT when there is no _javascript_ parsing/validation is applied? Using such a mode users will get:
- No warnings/error markers and/or annotations
- No outline/type hierarchy/override indicators.
- No
validation/content assist/refactoring allowed in _javascript_ Editor.
- _javascript_ editor will be as fast as just a text editor and will still be syntax-
- No more OOME errors
- (in future) Custom validators/content assist providers allowed.

This could really help with performance on big projects especially when JSDT doesn't plays the main role in project development.

Users may test such an option by replacing they JSDT from WTP M7 by the version built from my playground here:

Use the following command to build:
cd <YourProjects>/webtools.jsdt
mvn clean install -DskipTests=true -Pbuild-individual-bundles

Then install from local site <YourProjects>/webtools.jsdt/site/target/repository/ directory (available after successful build).

What do you need to make it fast - is just to set ECMAScript compliance level preference value to  "External Builder/Validator" on _javascript_->Validator preference page.

BTW, having such option could be really useful if you're using a product like and angularjs-eclipse - they're provide ECMA5 compatibility and work a really faster this way.

And as no parsing/validation/content assist and so on is available when "External Builder/Validator" option is selected, I'd like to ask users what features they are really need and use in JSDT?

Regarding the performance issues listed, I strongly see one  candidate to cut out from JSDT: It's override indicators that are doubling the performance glitches and adds almost nothing useful for users (imho). Should we cut it out?

What do you think?

Thanks in advance,
Victor Rubezhny,

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

Back to the top