Tomas, Svata it is possible that parsing is locking document and therefore Insert Break is waiting for document lock?

I saw this in csl parsing Bug #216029 , but I don't see it in java and j2ee in snapshot.

I will try to answer your questions if this helps - I can still reproduce this. But I have some doubt whether I can make a testcase easily because the file is under svn control, and dependencies exist between projects.

Tabbing to the Java file in he editor has the same effect. Undoing insert line has same effect.

From what I can see (so far), the problem is that JPQLValidation invokes org.eclipse.persistence.jpa.jpql.JPQLQueryHelper, which takes quite long time (1 invocation almost 40 seconds in the attache snapshot), and does not seem to be cancelable. The code completion can then be blocked until it finishes - while this is not visible in the attached dump, I don't see a way how the it could not block the CC. Its probably necessary to investigate how to make the validation cancelable.

Can you provide a hint what should be canceled and when?

 bht,
do you have named queries in your class? how many?

http://hg.netbeans.org/web-main/rev/33e28d781030 may be part fix/fix, should improve validation performance in case of multiple nq in a class

(In reply to comment #4)
> Can you provide a hint what should be canceled and when?

Its unfortunately unlikely to be easy, but: when JPAProblemFinder$ProblemFinderCompInfo's cancel method is called, it needs to stop doing what it is doing as soon as possible and return. It currently sets a flag on a context, which is fine by itself, but noone is checking for the flag inside JPQLQueryHelper, as far as I can tell. As the JPQLQueryHelper is (as I understand) a third-party code, it might be little bit tricky to cancel it. In a similar context, I run the third-party code in a separate thread, and hard-cancel it there, but it is not a nice solution in any way.

ok, thanks, will look into canceling also.


http://hg.netbeans.org/web-main/rev/04fe2f14a1bb some more optimization, number of javasource.runmodification.. calls should drop significantly with this and above changes.

Yes, the class has 4 named queries.

http://hg.netbeans.org/web-main/rev/f0cc35fdd043 do not check next query if task is canceled

please try dev build after a day or two as I can't reproduce the problem with some simple steps and I need feedback, in my opinion performance should be better now

Integrated into 'main-golden', will be available in build *201208010001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/33e28d781030
User: Sergey B. Petrov <sj-nb@netbeans.org>
Log: #216053 may be related, cause up 20 time fater validation in case of 60 queries in simple test case

Created attachment 122614 [details]
Snapshot after fix

Ran the same test with netbeans-trunk-nightly-201208010001-windows.exe

I cannot notice any improvement with this build yet.

I'm not sure if all 3 commits are in 201208010001

Jan,

Is there a better way to find type element?
In attached snapshot most tyme take 
Elements.getTypeElement call,
my fixes above only tries to minimize number of calls, but I'm not sure I can minimize this time, alos is it cancelable?

if there is nothing we can do with elements.get.. I'll make separate thread/hard cancel.
but it may have sense to check if it's valid to have 30 seconds in this method.

ps. should be patch candidate also.

Is there a way for me to see how the JPQLQueryHelper gets called (and how the Elements.getTE is invoked), so that I could debug it? It is not one invocation for 30+ seconds inside one call of Elements.getTE - the snapshot claims there were 38 invocations, but that would mean ~1 second per invocation, which still seems way too much to me (but the "samples" count may not be reliable). But would be nice to cancel at least between calls to Elements.getTE. Might be also possible to automatically cancel the getTE process, if that proves to be necessary.

thanks, I miss number of calls.

j2ee.persistence/src/org/netbeans/modules/j2ee/persistence/spi/jpql/TypeRepository.java

is class with these calls. 
simple use case:
create j2se project
create entity from db with all defaults (may be except package) from javadb sample database (DISCOUNT_CODE table for example).
you'll get DiscountCode class with a number of named queries, each validation for this class will use query helper, new lines will trigger validation.

The tested entity class contains named queries whose JPQL strings are broken down for better readability as follows:

"select\n" +
   "a.field1,\n" +
   "a.field2,\n" +
"from\n" +
   " MyEntity a,\n" +
...

Perhaps this causes additional performance degradation.

I guess it is hard for an IDE to process JPQL inside a Java class. Perhaps in future such JPQL can be read from separate JPQL files, or perhaps I have overlooked such functionality.

can you share your queries code?
30 invocations of getType after all 3 commits may happens only for very complex queries or something is wrong because query is split, it may not supported well but in my opinion shouldn't cause complex validation also

http://hg.netbeans.org/web-main/rev/4d42c10d44c9 cancel should be processed no more then one call in Eements.get..
It means in worst case from attached snapshot about 1 second instead of 40. on my system it's always withing several or dozen of milliseconds with some small project even with moderate level queries.

Integrated into 'main-golden', will be available in build *201208030001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/4d42c10d44c9
User: Sergey B. Petrov <sj-nb@netbeans.org>
Log: #216053 more complex cancel logic to skip long getTypeElement for imvalidated model

just a note, fix doesn't fix processor usage as it may be ok to use processor and  but it fix response of code completion invocation.

Hope may be considered as fixed, at least as P1 and on persistence side and even processor usage should be lower now I hope (shorter time at least in some cases). On other side can't say anything about "too much" in single Elements.getTE. 
Need verification for code completion and may be other affected actions.
bht are you agree, can you verify?

Please provide option to turn off useless CPU usage.

Unfortunately, I cannot see a difference. Installed netbeans-trunk-nightly-201208030001-windows.exe

Opened the entity class and let the system settle down, confirmed by task manager.

In constructor, created new line, typed this. - initiated code completion and waited 43 seconds for code completion. CPU was at 100% for the whole time.

The IDE created a snapshot automatically at
http://netbeans.org/bugzilla/show_bug.cgi?id=216053

I use many named queries. But I don't use the IDE support for named queries.

I don't want to get into this because of diminishing returns.

I try:

@Entity
@NamedQueries({
    @NamedQuery(name = AddressResidential.GET_BY_PERSON, query="select object(a) from AddressResidential a where a.person= :person")
})
public class AddressResidential {

Code completion does not work here as advertised at:
http://wiki.netbeans.org/NetBeans_72_NewAndNoteworthy#JPQL_and_named_queries_support

So I get this enormous penalty for something that I don't want to use, something that does not work and something I am not convinced that even making it work is worth the effort.

It is as ugly as supporting all these alien languages in JSP files.

Created attachment 122731 [details]
Snapshot after fix - new line only

I copied the relevant projects and opened them with a separate userdir with 7.2 release and 7.3 dev without importing settings.

In both cases, after deleting the userdir, CPU usage is still high but the code completion is fast.

I suspect that the reported case has a subversion complication because the copied test case does not have any subversion information. This could also be the reason why you don't see the problem.

In any case, I cannot see any difference between 7.2 release and 7.3 dev.

Created attachment 122735 [details]
Snapshot 7.2 release with code completion that failed to show

Contrary to my previous observation, I can reproduce this without svn, so svn might not be a factor.

With 7.2 and 7.3 dev, I can avoid the CPU penalty by inserting the new line and invoking code completion fast enough (very fast). Then the code completion is instant. After dismissing the code completion, CPU use rises to 100% and a repeated code completion takes 40 seconds to show.

It appears now that code completion cannot compete with the CPU use of this CPU-intensive task and it has to wait until that task finishes.

In my project, high CPU load is caused by a high number of entities even if these are not related to the entity being edited.

I was able to reduce the 100% CPU time from 40 secs to 6 secs by reducing the number of entities from 56 to 15. Performance improved gradually with numbers in between.

Perhaps one can make a test with a few hundred entities and get performance to an acceptable level.

My system generated snapshots are at http://statistics.netbeans.org/analytics/exception.do?id=604079

ok, thanks, it looks if cpu usage at 100% it just do not get cancel even as I tried to test with some thread.sleep() instead of 100% cpu, can you attach message.log also?

Created attachment 122778 [details]
logs in zip file

The log contains interesting entries at the end. I think there is a complication due to a dialog popping up "refreshing hints". Then the automatic error reporter started to interfere and at around the same time (don't know whehther before or after) there is a NPE in the log. I can easily create 30 second delays but sometimes it is better.

this one line "ignored cancel for 21,468 ms." is related, can't say why it's still ignored and why there are two lines one right after another yet, first cancel works good (in 0.6 seconds). it still means even cancel do not work properly.
npe seems related to a way I tried to fix the issue and will be just skipped in next builds.
regarding allow to disable cpu consumption, it may be an option too, but either feature of jpql validation need to be disabled in patch or new configuration should be added. in my opinion I need to play with canceling  first an try to make it working better.

I see quite a lot of warnings unrelated with newline but regarding time to complete something, not sure if it may be somehow related anyway. Will try to play with some dozens of entities.

just tried about 30 entities and about 30 simple named q in edited entity and still works fast enough with cancel ignored for about 100ms and only once per completion invocation, I see no second warning here. Tried also to add all libraryes I can add with "Add Library" and still have reasonable time.
the only problem I got is http://netbeans.org/bugzilla/show_bug.cgi?id=200332
after addition of a lot of dependencies to web project and cc during scanning, need to check if it's also related.

Jan, Tomas, did you get a chance to look into this issue? I have no more ideas what may cause slowness here for now.

Bernard, what do you mean by userdir remove? is it config or cache dir or both?

(In reply to comment #36)
> Jan, Tomas, did you get a chance to look into this issue? I have no more ideas
> what may cause slowness here for now.

I tried, but was not able (yet) to get to a state where there would be more than a few calls to Elements.getTE, and that these would take a significant amount of time. 

> 
> Bernard, what do you mean by userdir remove? is it config or cache dir or both?

a bit more optimization
http://hg.netbeans.org/web-main/rev/ac886697d0b8
should help to reduce number of getTypeElement calls in case of complex queries with a lot of usage of different object fields as this constructions like "{a}"."{b}" are tested as type elements by parser. please wait for integration.

Bernard, would you be willing to test a patch? The snapshots show a lot of time spent in File.listFiles, so I tried to cache the results. The patch is not good for "production" use (consumes quite a lot of memory, and there might be issues with clearing the cache), but could give us idea whether caching the listFiles result might help or not.

To apply the patch, place the jar file I am going to attach to:
${NETBEANS_INSTALL_DIR}/java/modules/patches/org-netbeans-modules-java-source
(java/modules should exist, patches/org-netbeans-modules-java-source will need to be created) and start the IDE. It should print something like this to the log on the startup:
INFO [org.netbeans.core.startup.NbEvents]: Module patch or custom extension: <path>/java-source-216053.jar

The patch should be compatible with a recent trunk builds, I can prepare similar patch for NetBeans 7.2 if desired.

To revert the effects of the patch, simply delete the jar.

Thank you.

Created attachment 122804 [details]
Binary patch for testing

I made large cases from a project that I opened with a freah userdir, nothing inherited with --userdir so I thought that covers config and cache, doesn't it?

30 entities would not be enough for a test. If you have a fast computer then perhaps 200. Performance goes down with rising numbers first a little then a lot. I have a slow computer, 2GHz, single core, 3Mb RAM

Where shal I copy the patch file?

(In reply to comment #43)
> Where shal I copy the patch file?

Into ${NETBEANS_INSTALL_DIR}/java/modules/patches/org-netbeans-modules-java-source
(java/modules should exist, patches/org-netbeans-modules-java-source will need
to be created) and (re-)start the IDE.

Thanks.

ok, will try to create more tomorrow, but also there should be one more commit to make things better in next build, I hope. (With assumption time is relatively equal for each Elemens.getTypeElement call), it's on persistence support side and also please tries patch above.

Integrated into 'main-golden', will be available in build *201208070001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/ac886697d0b8
User: Sergey B. Petrov <sj-nb@netbeans.org>
Log: #216053 optimize enum test, should drop number of getTypeElements even more

Created attachment 122819 [details]
logs after patch in zip file

logs with patch in
C:\Program Files\NetBeans Dev 201208030001\java\modules\patches\org-netbeans-modules-java-source\java-source-216053.jar

*** Bug 216494 has been marked as a duplicate of this bug. ***

*** Bug 216506 has been marked as a duplicate of this bug. ***

looks like number of entities doesn't matter, as I have about 1000 (but simple entities) and opening one in editor still leave memory consumption at 180mb level, near the same as opening usual java file. but it's in j2se project. and it's with very simple jpql inside.

yes I agree, we have 100s of entities and opening one with only 1 named query doesn't give problems; issues seem to arise when there are many nq o they are complex

(In reply to comment #51)
Could you provide heap dump to see memory usage?

Created attachment 122901 [details]
Snapshot while hung

I could open 15 entities in the editor. On each one, there was a CPU load of a few seconds. I waited for the CPU to get to 0 each time. At the 16th entity in the editor, the CPU stays at 100% indefinitely. It is very difficult to do anything with the computer after that. I took this snapsot during this period.

Created attachment 122902 [details]
thread dump text while hung

The last two files are without patch applied.

Bernard, could you please check memory usages (e.g. in jvisualvm, "Monitor" tab)? So that we know whether something is really slow, or whether the memory is tight (possibly due to a memory leak), slowing down the rest. Thanks.

In this state, visualjvm doesn't respond. I was lucky to get the thread dump, but only after killing NetBeans so I couldn'd save it. Under WinXP I tried with Windows Task Manager to lower the NetBeans.exe priority but this did not have any effect. I will try again, also I will give NetBeans more memory and will re-enable the patch.

Created attachment 122905 [details]
Thread dump while hung with patch

Created attachment 122906 [details]
Application snapshot while hung with patch

Now I have closed the IDE and the GUI is gone but the process still consumes 100%.

Created attachment 122907 [details]
Thread dump while hung with patch, IDE closed

Created attachment 122908 [details]
Application snapshot while hung with patch IDE closed

last hand is very strange as Name.toString() tale 15 seconds, but will replace code with a better solution as there is better method to compare name.

http://hg.netbeans.org/web-main/rev/ad57dfaae79a change compare and even more reduce in Elements.getTypeElement

I'm trying to generate 10000 entities in maven project and it takes longer in my opinion. Looks like I'll get a result tomorrow only and may be it's matter to reproduce slowness with validation.

(In reply to comment #63)
> 10000 
1000

Have uploaded a heap dump. Case: Patch applied, IDE closed, hung indefinitely after 15 entities opened in editor.

The files were created with the 7-zip utility, split in multiple zip files

216053_heapdump-1344503116093.zip.001
216053_heapdump-1344503116093.zip.002
216053_heapdump-1344503116093.zip.003
216053_heapdump-1344503116093.zip.004

uploaded at
http://deadlock.netbeans.org/hudson/job/upload/build

Integrated into 'main-golden', will be available in build *201208100001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/a14d1177500e
User: Sergey B. Petrov <sj-nb@netbeans.org>
Log: #216053 minor cleanup

http://hg.netbeans.org/web-main/rev/ba1cec2f2a36
http://hg.netbeans.org/web-main/rev/c099d7c90c4a
replace typeelements with persistentobject(wrapper with elemnthandle usage) and try to use one annotationmodelhelper for all resolve calls, may help to reduce memory usage.

autozoom,
can you try a build after above changes integration to check memory usage?

Integrated into 'main-golden', will be available in build *201208110001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/ba1cec2f2a36
User: Sergey B. Petrov <sj-nb@netbeans.org>
Log: #216053 replace typeelement usage with persistentobject usage in some places

I tried NetBeans Dev 201208120001 and now opening that same entity keeps memory at 600Mb.
Now it looks ok

netbeans-trunk-nightly-201208120001-windows.exe looks quite good. I am getting exceptions which are reported at http://statistics.netbeans.org/analytics/exception.do?id=605614 but I can keep working.

if @netbeans-trunk-nightly-201208120001-windows.exe looks quite good" 
hope can be considered as fixed now.

Integrated into 'main-golden', will be available in build *201208140001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/42c4a850f305
User: Sergey B. Petrov <sj-nb@netbeans.org>
Log: #216053 avoid call to getTypeElement for invalid model as it may be out of proper thread.

bht, autozoom
thanks for your efforts on this issue, I'm trying to make fix smaller and hope a bit more efficient, can you try one more build to see if it the same or better as 201208120001.

http://hg.netbeans.org/web-main/rev/2cc39b8de892 reuse Elements from cc/validation top classes instead of new one javasource creation/check long a.b.c.d cases in enum test

Integrated into 'main-golden', will be available in build *201208150001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/2cc39b8de892
User: Sergey B. Petrov <sj-nb@netbeans.org>
Log: #216053 - reuse java model from top of cc/validation instead of new javasource creation, more rubust enum test for long cases like a.b.c.d

Integrated into 'main-golden', will be available in build *201208170001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/ce30917740cf
User: Sergey B. Petrov <sj-nb@netbeans.org>
Log: #216053, #216956 check null

Integrated into 'main-golden', will be available in build *201208180001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/5098ce51a4ac
User: Sergey B. Petrov <sj-nb@netbeans.org>
Log: #216053, #216827 don't need to reparse annotation mirors as model is already created

I just tried build 20120818001, and still looks good: memory at 600Mb and editor very responsive.
But I have to point out one bad thing I didn't notice before: autocomplete for named queries only shows properties for the class, and not the properties that come from the @MappedSuperclass it inherits from.
This doesn't look good

thanks, then smaller patch may go into 7.2 patch.

regarding mapped superclass next is filed issue 217088

Integrated into 'main-golden', will be available in build *201208211308* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/e515274a3c8c
User: Sergey B. Petrov <sj-nb@netbeans.org>
Log: #216053, #216827 do not support enums in default package, it shoud be exremely rare case even if some providers may support and resolve it.

Could you please clarify what should go to the patch release and what should be tested then?

*** Bug 216888 has been marked as a duplicate of this bug. ***

it seems fix of 217413  need to be integrated too.
unfortunately there are a lot of changes,all is covered with http://hg.netbeans.org/web-main/log?rev=%23216053 except latest one mentioned above. do you need complete diff patch attached? as some mentioned changes are replaced with later changes.

to test: it's nice to try some big JPA project, try to open entities and check if named queries are parsed and if some minor(or big) modifications to these entities cause no big delays later in response to keyboard, or other nb actions.
(it's nice to modify and try second modification right after first and some random time later 1-2.. etc seconds)

Created attachment 123622 [details]
patch created from all changesets (isn't optimized)

Patch is created from all checgesets with hg export, may be optimized to contain only real diff

Created attachment 123648 [details]
Actual patch for 72

everything related to performance/memory usage optimization in jpql validation/completion is in the patch.
it's diff as it should be integrated into 7.2
previous attached patch contain occasional elements for html, there are no actual changes in html area.

everything is integrated into latest daily in trunk.

bht, can you please once again try last trunk build and let us know if you consider at as fixed? Verification in dev build is necessary in order to proceed with backporting of fix to 7.2 patch1. 
(There's a deadline for backporting - Fri 08/31)

Thanks in advance!



(In reply to comment #84)
> Created attachment 123648 [details]
> Actual patch for 72
> 
> everything related to performance/memory usage optimization in jpql
> validation/completion is in the patch.
> it's diff as it should be integrated into 7.2
> previous attached patch contain occasional elements for html, there are no
> actual changes in html area.
> 
> everything is integrated into latest daily in trunk.

My test with Build 201208290001 looks fine. Many thanks.

Thanks for fast verification! 
Sergey, please go ahead and backport. (http://wiki.netbeans.org/NetBeansPatchesProcess)

(In reply to comment #86)
> My test with Build 201208290001 looks fine. Many thanks.

thanks, I would like to wait for 217413 verification, fix rollback one part of http://hg.netbeans.org/main-golden/rev/2cc39b8de892
will it require to reverify 216053?

http://hg.netbeans.org/releases/rev/b9ed78da1a4c migrated to release72

Integrated into 'releases', will be available in build *201209010822* or newer. Wait for official and publicly available build.
Changeset: http://hg.netbeans.org/releases/rev/b9ed78da1a4c
User: Sergey B. Petrov <sj-nb@netbeans.org>
Log: #216053, #217413 improve perfomance/memory usage for jpql validation (common patch from all changesets)

*** Bug 217721 has been marked as a duplicate of this bug. ***

*** Bug 217615 has been marked as a duplicate of this bug. ***

*** Bug 217110 has been marked as a duplicate of this bug. ***

*** Bug 217836 has been marked as a duplicate of this bug. ***

*** Bug 218662 has been marked as a duplicate of this bug. ***

*** Bug 219179 has been marked as a duplicate of this bug. ***