This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 15756 - Close on parsed document is slow.
Summary: Close on parsed document is slow.
Status: CLOSED FIXED
Alias: None
Product: xml
Classification: Unclassified
Component: Code (show other bugs)
Version: 3.x
Hardware: PC Linux
: P2 blocker (vote)
Assignee: _ lkramolis
URL:
Keywords: ARCH, PERFORMANCE
: 18015 19827 (view as bug list)
Depends on: 17297
Blocks: 20532
  Show dependency tree
 
Reported: 2001-09-21 12:01 UTC by issues@www
Modified: 2005-03-09 04:28 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Patch to rollback (if fails) (1.64 KB, patch)
2002-06-03 20:06 UTC, _ pkuzel
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description issues@www 2001-09-21 12:01:02 UTC
Description: 

[FFJ Build 010616 CE , Red Hat Linux 6.2 with JDK 1.3.1]
 
Steps to reproduce:
-------------------
1) expand large XML document in Explorer
   (e.g REC-xml-19980210.xml)
2) open the document in TXT Editor
3) close the TXT Editor


Evaluation: 

xxx@xxxx 2001-06-27

We place reparsing of document to AWT thread to avoid concurent tree
modifications during result merging. 

A comment.
Comment 1 Petr Nejedly 2001-10-16 11:46:31 UTC
I believe it is caused by the same problem in
org.openide.text.PositionRef$Manager
and slow closing of .java file #11692

*** This issue has been marked as a duplicate of 11692 ***
Comment 2 _ lkramolis 2001-10-16 13:02:42 UTC
I think, it is not only caused by #11692. When TAX is built and user
close editor, then swing Document is also closed and TAX is re-parsed
from stream. And this re-parsing is very expensive, and may be it will
be main reason of poor performance.

Comment 3 _ lkramolis 2001-11-20 16:53:05 UTC
Depends on 17297 - new ???EditorSupport should better support two
document representations (Swing and TAX Documents).
Comment 4 Jan Chalupa 2001-11-27 17:39:05 UTC
Target milestone -> 3.3.1.
Comment 5 Jan Chalupa 2001-11-27 17:42:36 UTC
Target milestone -> 3.3.1.
Comment 6 _ pkuzel 2001-12-12 11:11:59 UTC
*** Issue 18015 has been marked as a duplicate of this issue. ***
Comment 7 _ pkuzel 2002-01-28 13:05:46 UTC
*** Issue 19827 has been marked as a duplicate of this issue. ***
Comment 8 Martin Schovanek 2002-04-19 15:06:59 UTC
Await near 1 min on documet close is realy long time.
Less patient user cat think that is deadlock 
Comment 9 _ pkuzel 2002-04-24 10:32:09 UTC

*** This issue has been marked as a duplicate of 22732 ***
Comment 10 _ lkramolis 2002-05-06 09:38:34 UTC
I do not think issue 22732 describes same problem -> reopened.
Comment 11 _ pkuzel 2002-06-03 20:06:38 UTC
Created attachment 6053 [details]
Patch to rollback (if fails)
Comment 12 _ pkuzel 2002-06-03 20:08:52 UTC
Patched. Could anybody review/rollback it. I have not found any side
effect, but you may know the code better.

Thanks
Comment 13 _ lkramolis 2002-06-04 08:09:24 UTC
Interesting. It could solve this problem with disable XML Tree Editor
module, but when enabled the problem still remains, I think.
Comment 14 _ lkramolis 2002-06-04 10:24:13 UTC
Sorry, I wrongly read != condition. Now I see different problem. Text
representation will never be removed when installed XML Tree Editor
module.
Comment 15 _ pkuzel 2002-06-05 15:02:52 UTC
Patch fixed it.

Now there is only visible slowdown while saving the document.
Hopefully it is tolerable for save action. 
Comment 16 Martin Schovanek 2002-07-24 12:16:44 UTC
VERIFIED
Comment 17 Quality Engineering 2003-07-02 08:41:15 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.