655 is SLOOOOOOOOOOOOW
My system is a dual P3-1GHz machine with 512MB of RAM and build 655 is
incredible slow... if I type quickly there is a noticeable lag (of 4-5
characters) in the editor. I can handle some slowdown for operations such as
refactoring but not in the editor... it's just waaaaaay too slow at the
moment. Before final release you really need to get the editor speed up.
请先登录再写评论。
Ian,
We've made a request to give more meaningful performance report already a
dozen of times. If you really want to help us, please send your problematic
file/project/sample file whatever you can, which can be used to reproduce
the problem. Our engineers will be happy to fix the performance problem.
--
Best regards,
Mike Aizatsky.
-
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
I can't do that - the code I'm working on is the property of my employer.
There are enough people reporting performance problems that clearly you have
some issues that need to be addressed. Sorry I can't provide more
information beyond the fact that my files vary wildly in size from a few K
to 40-50K and I'm using default settings. Slow is slow...
"Mike Aizatsky" <mike@intellij.com> wrote in message
news:ans7ti$d1m$1@is.intellij.net...
>
problematic
>
>
>
Ian wrote:
I don't think slow is slow : for instance, I don't experience your problems.
Reproducibility is the key for bug fixing. If you can't give your
projects away (common problems) all you can do is reproduce the problems
in a project you create from scratch.
In doing this, it is not too uncommon to might find that one's working
environment had a problem
Edo
>>Ian,
>>
>>We've made a request to give more meaningful performance report already a
>>dozen of times. If you really want to help us, please send your
>>file/project/sample file whatever you can, which can be used to reproduce
>>the problem. Our engineers will be happy to fix the performance problem.
>>
>>--
>>Best regards,
>>Mike Aizatsky.
>>----
>>JetBrains, Inc / IntelliJ Software
>>http://www.intellij.com
>>"Develop with pleasure!"
>>
>>
"Ian" <ilittlewood@hotmail.com> wrote in message
news:ans9rh$gid$1@is.intellij.net...
You could download a project from SourceForge (www.sf.net) and see if it's
slow too. If so, you could post the URL to the project here and everyone
could try it out and give performance feedback.
Ian,
As a quick experiment do the following:
1) Create a new project on the local hard-drive with nothing in it.
2) Create a new class in your new project. -- Do you see the slow-downs?
3) Copy one of your "problem" classes from your existing project into the new project. Do you see the problem?
In other words, is it something in your proprietary source code, or is it in your settings / environment. Half-splitting the problem between these two would most likely be of great use in debugging the problem.
Mike
Ian,
Please also check your todo settings. Does it help to remove all todo
patterns?
--
Best regards,
Mike Aizatsky.
-
JetBrains, Inc / IntelliJ Software
http://www.intellij.com
"Develop with pleasure!"
"Ian" <ilittlewood@hotmail.com> wrote in message
news:ans5vv$9eb$1@is.intellij.net...
as
>
>
So far all the performance issues I have seen so far were related
to bigger EJB projects (maybe more EJBs, definitely large EJBs).
If someone knows of a larger scale publicly_available EJB project
I'm sure IntelliGuys would appreciate it a lot.
And PLEASE, if someone is experiencing any significant slowdown
not related to EJB (e.g. no EJB configured at all) it would be really
helpful
to post it here with at least some detailed description...
r.
"Michael Kirby" <kirby@ess.mc.xerox.com> wrote in message
news:908360.1034009245405.JavaMail.jrun@is.intellij.net...
>
>
new project. Do you see the problem?
>
in your settings / environment. Half-splitting the problem between these
two would most likely be of great use in debugging the problem.
>
>
could it be that the file size is the key here? I never experienced
drastic performance issues until I touched a project with (generated)
files of > 500 lines. 40-50K is really pathologic.
Ian wrote:
>>Ian,
>>
>>We've made a request to give more meaningful performance report already a
>>dozen of times. If you really want to help us, please send your
>>file/project/sample file whatever you can, which can be used to reproduce
>>the problem. Our engineers will be happy to fix the performance problem.
>>
>>--
>>Best regards,
>>Mike Aizatsky.
>>----
>>JetBrains, Inc / IntelliJ Software
>>http://www.intellij.com
>>"Develop with pleasure!"
>>
>>
I just find the JSP stuff VERY slow. The normal java files are fine. The JSP is probably a factor of 10 times (or more) slower.
After reading your post, I checked how thinlet.java (from www.thinlet.com) is behaving in 655 build.
And ... is is much, much faster. Parsing warnings is taking now reasonable 10-20 seconds and it is done in the backgroud. In 651 build it was more than 2 minutes and the whole IDE was frozen for that period of time.
So just because there are many performance problems reported, it does not mean that they are not being fixed. In case I reported it is working now better than I would expect from 188KB java file.
Just give them a chance to find out what it is ;)
I, too, am having serious performance problems w/ an EJB project. What's more discouraging is that my files are not even big -- the largest is currently less than 300 lines!
I do not see the problem at all in non-EJB files. If I switch to an EJB file, the editor might freeze for 5-10 seconds and then oftentimes, each character stroke will have a .5 to 1 second delay.
I followed the suggestion of removing all todo patterns -- no change.
I will try to create a dummy EJB project and see if I can reproduce it and send you a copy. In the meantime, any investigation by IntelliJ will definitely be appreciated!
Cheers,
-jt
A few observations:
1. typing delays when editing very big (2000-6000 lines) java files are most
of the time caused by GC activity (jdk1.4.0), however new line (enter) seems
to always cause a delay. Changing the heap size doesn't really help (i've
tried 128, 256, 384). Auto-complete is sometimes delayed too (haven't been
able to see any pattern here).
2. delays would not occur if the file is neat and well structured, they
happen when the file contains very long methods with good amount of nested
blocks. Most if not all open source projects are pretty neat so they will
not make a good example. Since the files I have here are property of the
company I work for, I won't be able to send them. On the other hand it
shouldn't be very difficult for you to generate one.
3. parsing large xml files is now (#655) good and does not affect the typing
speed, however once the particular file is added as a build file things get
a bit out of control. Typing 2-3 characters often causes idea to freeze for
5-10 seconds. Mike, I'll send a modified version of that file directly to
you.
Just a suggestion, why don't you try to generate an extremely long file,
let's say 50 or 100K lines with high complexity, and make sure it can be
edited (parsing could take an hour but that shouldn't matter, should it)? It
may sound unreasonable, but it may be a way to reproduce what other users
are experiencing.
Best regards,
--Nikolay
"Mike Aizatsky" <mike@intellij.com> wrote in message
news:ans7ti$d1m$1@is.intellij.net...
>
problematic
>
>
>
I noted a slow down in the builds 655 and 657. At the moment every time I make a copy of a selected text I can move the caret once and then all stops for about 20-30 sec. (??)
Regards,
Martin
Ok, just ~10 sec., but thats still a long time.
Just closed some "decompiled" class files (included from jar) and a jsp file that was been as open files in my project for some days now and it helped (???).
Regards,
Martin
I have to say ANT build files in 662 are lightning fast. Amazing job guys!!!
Still have problems with Java files though, I have the impression that 660
was behaving better.
I had to debug one of these 6000+ lines files today and here's what i've
experienced:
- during the first 10-15 seconds of parsing/analyzing the editor is almost
non-responsive (can't move the cursor, can't switch to another file, etc.)
- debugging is very slow until the whole file is parsed and analyzed.
regards,
--nikolay
oh btw, should i open an SCR?
"Nikolay Nikolov" <nnikolov3@comcast.net> wrote in message
news:anvg73$avb$1@is.intellij.net...
most
seems
typing
get
for
>
It
>
>
>
a
reproduce
>
>