Bug 345860 - [performance] JSDT chokes on javascript files with long lines (>500k long)
Summary: [performance] JSDT chokes on javascript files with long lines (>500k long)
Status: NEW
Alias: None
Product: JSDT
Classification: WebTools
Component: General (show other bugs)
Version: unspecified   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 major with 2 votes (vote)
Target Milestone: Future   Edit
Assignee: Project Inbox CLA
QA Contact: Chris Jaun CLA
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2011-05-15 17:42 EDT by navid.mehregani CLA
Modified: 2018-02-08 15:18 EST (History)
5 users (show)

See Also:


Attachments
JSDT hangs when parsing this JavaScript file (511.79 KB, text/plain)
2011-05-15 17:44 EDT, navid.mehregani CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description navid.mehregani CLA 2011-05-15 17:42:24 EDT
Build Identifier: 

When opening a large JavaScript file on a Mac, JSDT enters into an infinite cycle of parsing the file.  The user is never given a chance to interact with the editor.  Eclipse has to be shut down ungracefully. 

Reproducible: Always

Steps to Reproduce:
1. Using the latest release of Indigo build for 'JavaScript Web Developers', create a new JavaScript project
2. Copy and paste the attached JavaScript file in the project
3. Open the file and try and interact with the editor.  CPU shoots up to 100% and memory usage increases as well.  Parsing never seems to get completed and Eclipse becomes unresponsive.
Comment 1 navid.mehregani CLA 2011-05-15 17:44:52 EDT
Created attachment 195686 [details]
JSDT hangs when parsing this JavaScript file
Comment 2 Nitin Dahyabhai CLA 2011-05-19 01:55:27 EDT
It seems to complete parsing for me with M7, although it does consume a large amount of memory before settling down.  Even the plain text editor has some sluggishness when the file has 500,000 characters on one line.
Comment 3 Marc CLA 2011-06-05 06:36:58 EDT
Yes, well, this problem has been around for years and years and years across AFAIR at least 3 major version releases of Eclipse. In fact, I can't remember ever having been able to edit a significant Javascript file on Eclipse without major problems.

Just for fun I tried downloading Indigo M6 to see if it had finally been fixed. It started at 180Mb. I opened one Javascript file. It went up to 450 Megs and then stabilized. I then opened another Javascript file. At first memory use fell back to 230Megs, could it be finally be fixed? I then switched the editor back to the first Javascript window and the explosion began. 400, 500 finally maxing out at 901M of 925M. Overall memory use 1,3 Gb (Windows) with just two Javascript files open. Eclipse was still responsive, hoorray. Not impressed. At all. I wonder if the Javascript team takes itself serious
Comment 4 Nitin Dahyabhai CLA 2011-06-06 02:52:11 EDT
Marc, your dismissive tone in response to our efforts isn't appreciated.  A number of fixes (such as bug 345797) didn't make the cutoff for 3.3.0, so you'll find them in the upcoming 3.2.5 and 3.3.1 releases.  I _am_ able to open 3 copies of the attached file with M7 settling down to under 500MB of heap usage while the maximum is set at 700M with little noticeable swapping happening, but the excessive line length still leaves us with unusable performance _in the editor_, hence this bug remaining open.  Parsing _did_ complete for me.
Comment 5 Marc CLA 2011-06-06 04:05:24 EDT
@Nitin. Well, I understand that that sucks. However, this issue has been around for so long, I'm truly frustrated with what I perceive as the lack of serious attention to it. Hence my tone.
Comment 6 Randy Hudson CLA 2012-11-27 13:17:30 EST
My IDE is currently locked from this issue.  I accidentally opened a compressed javascript file, and it's taking long enough that I had time to find this bugzilla, start commenting, and it still hasn't returned.

I've seen a related issue too.  When opening a file with everything on one line, I would do a search and replace to insert newlines into the file.  The search and replace seems to take in insane amount of cycles to complete.  My suspicion is that the UI (syntax highlighting?) is being updated for every single replacement, of which there are many.  The workaround is to open the file in the plain text editor and do the search and replace there.
Comment 7 Christopher Meacham CLA 2018-02-08 15:18:25 EST
I'm still seeing this in Oxygen.2 Release (4.7.2) but it only happens in select situations.

The file has a line that is 976,797 characters long. If I open it, eclipse locks up with what looks like the line being overwritten multiple times, leaving what looks like hieroglyphics or corrupted file text. If I don't open it, but perform a file search containing a term contained in the file, eclipse locks up for a minute and then the search results box turns solid blue.

To cause the blue box, I'd guess that some buffer is recycling and the hieroglyphics are being written to multiple lines in the search results box while the highlighting of the line ends up following the same pattern causing the entire box to apply highlighting multiple times.

I'd love to help out on this but I'm a C++ focused programmer, and currently overloaded at that. If I can provide any cursory testing or more information to reproduce the issues, please let me know.