editor is really slow #3945

floitschG · 2012-06-30T14:07:40Z

I have already submitted a feedback on the slowness of the editor. But since that's probably difficult for you to track down I also run jstack every second for some time.
I have attached the output of the stack dumps. (Not sure it will help, but maybe there is something in there that points you to the problem).

Attachment:
jstack (4.52 MB)

clayberg · 2012-06-30T20:18:02Z

Set owner to @danrubel.
Added this to the M1 milestone.

clayberg · 2012-07-02T13:25:40Z

This looks like slowness caused by a low memory situation and (my guess) swapping.

We should up the default max memory to 2GB for the Editor. 1GB is not enough for serious development.

floitschG · 2012-07-02T16:18:15Z

I'm running with 4GB now. The interruptions are less often now, but when they hit I still have 2 secs lag before a new character appears.

danrubel · 2012-07-02T16:35:17Z

Just to confirm we are on the same page... you are saying that you have modified the default DartEditor.ini file (see below) to have -Xmx4096m ? and perhaps also something like -XX:MaxPermSize=512m ?

-consoleLog
-data
../../../workspace
-vmargs
-Dosgi.requiredJavaVersion=1.6
-XX:MaxPermSize=256m
-Xms40m
-Xmx1024m
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-Declipse.vm=/System/Library/Frameworks/JavaVM.framework
-Xdock:icon=../Resources/dart.icns

Set owner to @floitschG.
Added NeedsInfo label.

floitschG · 2012-07-02T17:25:33Z

Didn't change the MaxPermSize, but yes for the Xmx4096.

ricowind · 2012-07-03T11:26:54Z

This is easily reproducible by simply loading the lib/compiler and just editing a few files. Could this be a memory leak, it seems this is getting worse and worse after a few hours of (actually pretty light) usage. Saving is also taking considerably longer now than before. I saw 20+ second pauses by simply adding a simple void function with an empty body and saving (just writing the function is also slow due to the lag when actually writing, it seems that if you pause for just a second there is a considerable lag when you start typing again)

danrubel · 2012-07-03T21:17:50Z

Thanks for the suggestions.

I ran build 9258 and opened the lib/compiler ... all was fine.
The editor continued to be responsive after 5 minutes of editing.
I'll leave it running in the background and periodically test responsiveness.

I'm testing this on Mac it appears you are using Linux and OpenJDK... I'll test on that next.

In the meantime...
Does "Re-analyze Sources" help?
What if you shutdown, delete your "workspace" directory, then restart and open those directories?
What folders do you have open?
Do you have any files/directories marked "Do Not Analyze" ?

cc @ricowind.

floitschG · 2012-07-04T09:05:15Z

I haven't tried "Re-analyze Sources" yet.
Deleting the workspace directory does not help.
Open folder: lib/compiler
Marked as "Do Not Analyze": lib, tools (the whole directories), and all other individual files that have errors.

It seems that the editor is behaving better now. I attributed that to the fact that I'm now running with MaxPermSize=512m and Xmx4096m, but, for testing, I switched back to the defaults yesterday evening, and I was able to edit Dart code again.
I will continue running in that configuration and see if the slowdowns come back.

floitschG · 2012-07-04T16:22:01Z

With the default settings I get again horrible performance (waiting 2 minutes to recover after a save). I'm not sure what exactly eats up the memory, though.
I have attached the jstack output while I was waiting.
I furthermore dumped the heap (attached two screenshots).

Attachments:
jstack (45.04 KB)
heap_histogram.png (193.23 KB)
instance_count.png (235.93 KB)
heap_summary (1.24 KB)

floitschG · 2012-07-10T15:58:39Z

Switching priority to High. This makes the editor unresponsive and hurts usability.

Even with 4 gigs I eventually run out of memory:

$ PATH=/usr/local/buildtools/java/jdk-64/bin:$PATH jmap -heap 2695
Attaching to process ID 2695, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 19.0-b09

using thread-local object allocation.
Parallel GC with 13 thread(s)

Heap Configuration:
   MinHeapFreeRatio = 40
   MaxHeapFreeRatio = 70
   MaxHeapSize = 4294967296 (4096.0MB)
   NewSize = 1310720 (1.25MB)
   MaxNewSize = 17592186044415 MB
   OldSize = 5439488 (5.1875MB)
   NewRatio = 2
   SurvivorRatio = 8
   PermSize = 21757952 (20.75MB)
   MaxPermSize = 536870912 (512.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 523173888 (498.9375MB)
   used = 291310064 (277.81492614746094MB)
   free = 231863824 (221.12257385253906MB)
   55.68130800901134% used
From Space:
   capacity = 179961856 (171.625MB)
   used = 179909224 (171.5748062133789MB)
   free = 52632 (0.05019378662109375MB)
   99.97075380240577% used
To Space:
   capacity = 444661760 (424.0625MB)
   used = 0 (0.0MB)
   free = 444661760 (424.0625MB)
   0.0% used
PS Old Generation
   capacity = 2863333376 (2730.6875MB)
   used = 2737579344 (2610.7591094970703MB)
   free = 125754032 (119.92839050292969MB)
   95.60812467545519% used
PS Perm Generation
   capacity = 61341696 (58.5MB)
   used = 61295616 (58.4560546875MB)
   free = 46080 (0.0439453125MB)
   99.9248798076923% used

Removed Priority-Medium label.
Added Priority-High label.

scheglov · 2012-07-10T19:52:32Z

How many opened files do you usually have when memory problem happens?
Do you observe any correlation between number of opened files and slowness?

floitschG · 2012-07-11T06:02:34Z

3 open views.
at the moment I have 5, 12, and 3 files open.

floitschG · 2012-07-11T07:03:59Z

Forgot to say: I didn't notice any correlation between the number of opened files and slowness. When it gets slow again I will see if closing some files will free the memory.

floitschG · 2012-07-12T12:35:31Z

Just had this problem with 3 opened files. The editor is getting unresponsive.
I just downloaded a clean version of the editor with a fresh workspace. No other file was ever opened before.

Attaching to process ID 15306, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 19.0-b09

using thread-local object allocation.
Parallel GC with 13 thread(s)

Heap Configuration:
   MinHeapFreeRatio = 40
   MaxHeapFreeRatio = 70
   MaxHeapSize = 1073741824 (1024.0MB)
   NewSize = 1310720 (1.25MB)
   MaxNewSize = 17592186044415 MB
   OldSize = 5439488 (5.1875MB)
   NewRatio = 2
   SurvivorRatio = 8
   PermSize = 21757952 (20.75MB)
   MaxPermSize = 268435456 (256.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 119341056 (113.8125MB)
   used = 38211896 (36.44170379638672MB)
   free = 81129160 (77.37079620361328MB)
   32.01906978265719% used
From Space:
   capacity = 119275520 (113.75MB)
   used = 0 (0.0MB)
   free = 119275520 (113.75MB)
   0.0% used
To Space:
   capacity = 119275520 (113.75MB)
   used = 0 (0.0MB)
   free = 119275520 (113.75MB)
   0.0% used
PS Old Generation
   capacity = 715849728 (682.6875MB)
   used = 629651632 (600.4825897216797MB)
   free = 86198096 (82.20491027832031MB)
   87.95863256932047% used
PS Perm Generation
   capacity = 58654720 (55.9375MB)
   used = 58254424 (55.555747985839844MB)
   free = 400296 (0.38175201416015625MB)
   99.3175382987081% used

clayberg · 2012-07-17T17:57:36Z

Do you still have this issue with the latest build? There have been some very significant performance and memory usage improvements made over the last few days.

floitschG · 2012-07-18T13:13:08Z

Current build seems to be much better.
However I think there is still a memory leak.

I used this editor yesterday during the afternoon, and continued using it today. Things start to get slow again. I'm pretty sure that a restart of the editor will help, though.

Note: I frequently replaced the files in the background (git checkouts). This yields tons of errors, which I quell by "don't analyze"/"analyze" (issue #3863). Could be that this is partly responsible for the memory leak.

build 9695:
Attaching to process ID 15626, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 19.0-b09

using thread-local object allocation.
Parallel GC with 13 thread(s)

Heap Configuration:
   MinHeapFreeRatio = 40
   MaxHeapFreeRatio = 70
   MaxHeapSize = 1073741824 (1024.0MB)
   NewSize = 1310720 (1.25MB)
   MaxNewSize = 17592186044415 MB
   OldSize = 5439488 (5.1875MB)
   NewRatio = 2
   SurvivorRatio = 8
   PermSize = 21757952 (20.75MB)
   MaxPermSize = 268435456 (256.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 119341056 (113.8125MB)
   used = 70571600 (67.30232238769531MB)
   free = 48769456 (46.51017761230469MB)
   59.13438540379599% used
From Space:
   capacity = 119275520 (113.75MB)
   used = 0 (0.0MB)
   free = 119275520 (113.75MB)
   0.0% used
To Space:
   capacity = 119275520 (113.75MB)
   used = 0 (0.0MB)
   free = 119275520 (113.75MB)
   0.0% used
PS Old Generation
   capacity = 715849728 (682.6875MB)
   used = 700314096 (667.8715667724609MB)
   free = 15535632 (14.815933227539062MB)
   97.82976351148379% used
PS Perm Generation
   capacity = 61997056 (59.125MB)
   used = 61975752 (59.10468292236328MB)
   free = 21304 (0.02031707763671875MB)
   99.96563707799287% used

scheglov · 2012-07-18T13:36:03Z

Could you please next time generate heap dump, compress it and send to the Editor team or upload somewhere? So, we could see where is problem exactly.

http://docs.oracle.com/javase/6/docs/technotes/tools/share/jmap.html

danrubel · 2012-08-03T18:16:50Z

I think this is now fixed. Please reopen if you see this problem again.

Added Fixed label.

floitschG added Type-Defect P1 A high priority bug; for example, a single project is unusable or has many test failures labels Aug 3, 2012

floitschG self-assigned this Aug 3, 2012

floitschG added this to the M1 milestone Aug 3, 2012

AndreyPavlenko mentioned this issue Dec 1, 2020

Stack Overflow on compilation #44362

Closed

This issue was closed.

editor is really slow #3945

editor is really slow #3945

Comments

floitschG commented Jun 30, 2012

clayberg commented Jun 30, 2012

Uh oh!

clayberg commented Jul 2, 2012

Uh oh!

floitschG commented Jul 2, 2012

Uh oh!

danrubel commented Jul 2, 2012

Uh oh!

floitschG commented Jul 2, 2012

Uh oh!

ricowind commented Jul 3, 2012

Uh oh!

danrubel commented Jul 3, 2012

Uh oh!

floitschG commented Jul 4, 2012

Uh oh!

floitschG commented Jul 4, 2012

Uh oh!

floitschG commented Jul 10, 2012

Uh oh!

scheglov commented Jul 10, 2012

Uh oh!

floitschG commented Jul 11, 2012

Uh oh!

floitschG commented Jul 11, 2012

Uh oh!

floitschG commented Jul 12, 2012

Uh oh!

clayberg commented Jul 17, 2012

Uh oh!

floitschG commented Jul 18, 2012

Uh oh!

scheglov commented Jul 18, 2012

Uh oh!

danrubel commented Aug 3, 2012

Uh oh!