Irida (3290) - Editor is slow / chunky during edits

I have been have a continued problem with Irida builds where the editor is sluggish when editing java or jsp files.
In general, the problem occurs when making edits to the file like reformat a line, cut a line, etc.

I saw some improvement after IDEADEV-575 "Copying/cutting code blocks the UI for approx. one second" was fixed in 3282, but it is still much slower and less responsive than by IDEA 4.5.3.

If I press and hold CTRL+D down to delete a bunch of lines,
or press and hold SHIFT+TAB to format a bunch of lines, or
press and hold RETURN to insert a bunch of lines, you can
compare Irida 3290 vs 4.5.3 running at max speed.

For these tests, Irida 3290 still pauses and starts
updating in large chunks. And usually after the last update,
it would pause another 5-10 seconds before I could regain
control.

4.5.3 is super smoooth; I can see each line delete, each
line reformat, and each newline inserted. There is no pause
/ lockup at the end.

Please investigate this further; I would rather not lose
the buttery smoothness of 4.5.3 when upgrading to Irida.

I don't know if it matters, but I am runing on Windows XP SP2 P4 2.8 Ghz 1GB memory. My workspace has about 6000 java / jsp / javascript / css files.

I have uploaded some cpu snapshots to ftp://ftp.intellij.net/.uploads

repeated_cutline_CTRLD_pasteline_CTRLV_3290_alex_15.04.2005_23.09.14.zip
repeated_deletelines_CTRL+D_3290_alex_15.04.2005_23.05.39.zip
repeated_indentlines_SHIFT+TAB_3290_alex_15.04.2005_23.12.36.zip
repeated_newline_RETURN_3290_alex_15.04.2005_23.07.16.zip

BTW I had some trouble ftp-ing the files. Using Windows XP ftp cmdline, doing a "dir" or a "put" was hanging most of the time. Don't know if that is because of windows ftp command, intellij ftp server, or crappy network connections. I have an graphical ftp client, but it didn't work because it didn't let me cd to ".uploads". It might be nice if you just change this to "uplaods".

-Alex



0

Danny van der Rijn wrote:

+10


Perhaps the dev team saves performance optimizations to the end of the
development cycle? that's what we do around here...

I think in general all EAPs were slower than released versions, but I'm
not sure.

0

As with every single EAP run so far things always get slower then are optimized towards the end of the EAP.

0

Obviously. What I'm saying is that they have gotten so slow, that I am no longer able to use the EAP and give feedback until they improve somewhat.

0

Obviously. What I'm saying is that they have gotten
so slow, that I am no longer able to use the EAP and
give feedback until they improve somewhat.


Really? Didn't seem that bad to me. Definitely slow but still usable.

0

In article <22856907.1113957777788.JavaMail.itn@is.intellij.net>,
Glen Stampoultzis <glen.stampoultzis@sensis.com.au> wrote:

Obviously. What I'm saying is that they have gotten
so slow, that I am no longer able to use the EAP and
give feedback until they improve somewhat.


Really? Didn't seem that bad to me. Definitely slow but still usable.


Typing for me today while debugging a swing app was just way slow.
Switching to a different project, more web app, did not exhibit this
problem. I was trying to think of ways to record and report this
problem.

R

0

I understand that EAP could have performance problems which get optimized later
in the release, but... we're talking about basic editor commands like cut,
paste, reformat, etc. I don't think those are undergoing major enhancements in
Irida, so why should they be slower? For that matter, I don't remember this
kind of persistant editing slowness / chunky updating in Aurora/4.0.x EAP and
Pallada/4.5.x EAP.

As I understand it, the problem has something to do with the PsiTree
information updating after edits are made. I originally thought it might have
to do with the error hilighting which has had major improvements/changes in
Irida and many more default warnings are turned on, plus I had turned on many
more myself. But I changed the error hilighting parse delay to 10 seconds and
also changed my default error hilighting profile to match 4.5.x, but the
editing slowness and chunkiness remained. Maybe JetBrains refactored the java
editor to mesh with the new language open api, and that introduced problems.

The examples I gave about deleting multiple lines, reformating multiple lines,
etc. were intedned to help show the difference between Irida and 4.5.x.

But I am experiencing pauses/chunky updates all the time while doing simple
editor commands like delete char/word/line, insert chars, move cursor, cut/copy/
paste, etc., which is very annoying. Writing / Editing signficant amounts of
code is very painful with Irida at the moment, so I have fallen back to 4.5.x
for work. I have only been using Irida to try out new inspection features and
to provide feedback like this. (I'm usually one of the crazy fools using the
latest EAP for my real work. I don't remember having to step back from Aurora
or Pallada due to persitant editor slowness.. )

I am raising a big red flag now to make sure this problem gets addressed. I don'
t see any reason why editing code should be any slower in Irida than in 4.5.x;
For me, the current slowness, chunky updating, and pauses negate all the new
features added to Irida.

Right now, I havne't seen JetBrains even acknowledge this problem. So I suggest,
if you are also experiencing editor slowness, chunky updating, pausing/hanging
after doing editing operations, please post your experiences also.


0

Nobody doubts their ability to improve performance; it's still important to submit these kinds of posts so that there's written data about when and what things started slowing down.

0

Patrik Andersson wrote:

Nobody doubts their ability to improve performance; it's still important to submit these kinds of posts so that there's written data about when and what things started slowing down.


yeah i guess so..

0

I use an Apple Powerbook G4 1.5GHz with 512 MB DDR 333 for developing my Java desktop apps.
Not the fastest machine on earth I agree, but still pretty decent.

I always use the latest EAP, and I often get very irritated with how slow the editor responds for simple source code edits, even with small java projects.
Copy/Paste is the perfect example.
When this happens, the memory indicator on the right-hand-side of the status bar seems to show that garbage collection just occurred...
I don't know if this can help.

IMHO, IDEA is the best Java editor, and I don't even use all the J2EE and Debugging features ! I love the wonderful language-aware code-writing assistance, powerful code navigation, Ant integration, refactorings, unmatched auto-import, pretty-formatting, inline-templates, etc...

I just wish IDEA wasn't so slow (temporary lockups) for simple code editing...

0

I don' t see any reason why editing code should be any slower in Irida

than in 4.5.x;
That's because you do not have access to the source code and project architecture
internals probably? :)

Right now, I haven't seen JetBrains even acknowledge this problem.

We do.

Well, a few tech details would probably shed some light on what's going on
here. It's all due the formatter. Whenever you press enter we invoke formatter
to gather correct caret position in the next line. Whever you paste we invoke
formatter to calc the indentation of the block pasted. And so on. Somewhere
in the middle of current EAP those formattings became non-incremental. I.e.
we happen to format whole file (copy of course) in the background. So, the
bigger file is the slower new-line-action or paste works.

Good news are we almost rewritten that. The fixes should be available in
a couple of weeks maximum.

-


Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"


0

That's great news !
Looking forward to experience the changes

-


It's all due the formatter. Whenever you press enter we invoke formatter
to gather correct caret position in the next line. Whever you paste we invoke
formatter to calc the indentation of the block pasted. And so on. Somewhere
in the middle of current EAP those formattings became non-incremental. I.e.
we happen to format whole file (copy of course) in the background. So, the
bigger file is the slower new-line-action or paste works.

Good news are we almost rewritten that. The fixes should be available in
a couple of weeks maximum.
-


0

Well, at least partially. Overall editing performance should be better still
we're planning more work there to be done.
-


Maxim Shafirov
http://www.jetbrains.com
"Develop with pleasure!"

Is this fixed by 3311?



0

请先登录再写评论。