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.
Summary: | Dragging and dropping very large HTML table into PHP Web Page makes IDE unresponsive and after renders strangely (see attached) | ||
---|---|---|---|
Product: | editor | Reporter: | maghiel <maghiel> |
Component: | Parsing & Indexing | Assignee: | Tomas Zezula <tzezula> |
Status: | VERIFIED FIXED | ||
Severity: | normal | CC: | mfukala, mmirilovic, Selpi, sks3286, vriha |
Priority: | P4 | Keywords: | PERFORMANCE |
Version: | 7.0 | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
DnD large html table result
A snapshot taken during shifting approx. 45000 html lines. A snapshot taken during shifting approx. 45000 html lines with disabled filling of stacktraces Screenshot after sometime (tried to maximize and restore window first, so controls disapeared) another screenshot |
Description
maghiel
2011-03-14 12:16:54 UTC
Created attachment 106976 [details]
DnD large html table result
I have similar experience. In fact, on my WinXP system, the CPU utilisation goes up to a full 100% after which I am forced to "End task tree" for the IDE since the NB IDE stops responding to any input. I experienced the same problem during my RC1 certification test, so this bug is confirmed. Batch reassigning. Editor area. The error also appears in Ubuntu Linux, bug confirmed while performing the test on RC 7.0.1 Reproducible in 7.1dev. Same for .html files so reassigning to html (it's its pallete). 1) I cannot reproduce the painting problem. 2) If I insert 200x200 table into an html file most of the CPU time is spent in a. very little time in html formatting ... getTagChildren() method - fixed in web-main#3f365fc85630 b. document.insert/removeUpdate() -> o.n.m.parsing.impl.event.resetState() which schedules a RP task (for reparse likely) but this involves creation of RP$SlowItem.fillInStactrace() which is terribly slow. the #b case is more nicely reproducible if you then select the whole file and invoke shift line action -> most of the time spent in document updates (isolated line shifts) causing the RP$SlowItem creation Since the issue is easily reproducible I'm not attaching any thread snapshots here. I'm not sure what the right component should be - likely parsing.api since its support schedules that many RP tasks. Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/3f365fc85630 User: Marek Fukala <mfukala@netbeans.org> Log: #196669 - HtmlIndenter caching of tag's children In reply to comment #8. >I'm not sure what the right component should be - likely parsing.api since its support schedules that many RP tasks. Parsing api does not schedule RP tasks, it just reschedules single one. Please reevaluate. (In reply to comment #10) > In reply to comment #8. > >I'm not sure what the right component should be - likely parsing.api since its support schedules that many RP tasks. > Parsing api does not schedule RP tasks, it just reschedules single one. Please > reevaluate. I'm sorry I wanted to write ...schedules that many RP *items*. Please re-read my comment above: b. document.insert/removeUpdate() -> o.n.m.parsing.impl.event.resetState() which schedules a RP task (for reparse likely) but this involves creation of RP$SlowItem.fillInStactrace() which is terribly slow. RP$Task.schedule() creates the RP$SlowItem. > ...schedules that many RP *items*.
To be really accurate:
Parsing API schedules one task many times which involves creation of RP$SlowItem on each RP$Task.schedule(...).
The evaluation is a bit "nonsense".
>Thee are document.insert/removeUpdate fired by document
> b. document.insert/removeUpdate() -> o.n.m.parsing.impl.event.resetState()
>which schedules a RP task (for reparse likely) but this involves creation of
>RP$SlowItem.fillInStactrace() which is terribly slow.
>RP$Task.schedule() creates the RP$SlowItem.
The reason why the schedule is done is to collapse the events, so the category is wrong.
Better is to attach the snapshot.
(In reply to comment #13) > The evaluation is a bit "nonsense". > > >Thee are document.insert/removeUpdate fired by document > > b. document.insert/removeUpdate() -> o.n.m.parsing.impl.event.resetState() > >which schedules a RP task (for reparse likely) but this involves creation of > >RP$SlowItem.fillInStactrace() which is terribly slow. > >RP$Task.schedule() creates the RP$SlowItem. > > The reason why the schedule is done is to collapse the events, so the category > is wrong. > Better is to attach the snapshot. Snapshot would definitely be better, but from the description it seemed that the problem Marek sees is that Task.schedule is creating stack traces and is being called a lot. I do not think that the real problem is that Task.schedule is being called many times - its the duty and point of the RP to handle that. The problem is the stack trace creation, which is (say) an unfortunate decision in the platform. I would propose to simply disable the stack trace creation, by changing: private static final RequestProcessor RP = new RequestProcessor ("parsing-event-collector",1); => private static final RequestProcessor RP = new RequestProcessor ("parsing-event-collector",1, false, false); Not sure if that helps in the original case (the stacktrace creation is enabled only when assertions are enabled, and assertions were almost surely disabled in 7.0RC1). I've already this this change. But I doubt it's real slowness, it's rather safe point. The following code: long s = System.currentTimeMillis(); for (int i=0; i<100000; i++) { StackTraceElement[] st = Thread.currentThread().getStackTrace(); } long e = System.currentTimeMillis(); System.out.println(e-s); takes 100000 stack traces and it takes 356ms. >(In reply to comment #13)
>> The evaluation is a bit "nonsense".
>I'm not sure what the right component should be - likely parsing.api since its
>support schedules that many RP tasks.
Why nonsense? The issue should possibly be filed against platform (RequestProcessor) rather than parsing.api. I understand the need for the events aggregation, I was just wondering if you could possibly do it in a RP without the filling stacktraces.
I may attach the snapshot but since as I've already said it is so easy to reproduce anyone can make own in a minute.
The category is wrong and probably it's not problem at all, see comment #15. This is what I've complained about. Created attachment 112660 [details]
A snapshot taken during shifting approx. 45000 html lines.
~16 seconds (of ~28) is spent in the RP$SlowItem creation
Created attachment 112662 [details]
A snapshot taken during shifting approx. 45000 html lines with disabled filling of stacktraces
>The category is wrong and probably it's not problem at all, see comment #15.
>This is what I've complained about.
The first snapshot contains just the part where the RP$SlowItem-s are created.
The second one spans over the whole "shift" operation where I've disabled the filling in stacktraces.
The whole line shift operation is approximately 2 times faster (~ 14seconds instead of the ~30 with filling in stacktraces enabled).
Thanks Marku Changed SI to FI in jet-main 19512d556e0d. But from real time measurement of shifting 3856 lines of HTML file only 811ms is spent in RP.T.schedule (SlowItem), and the SI is only in dev builds. Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/19512d556e0d User: Tomas Zezula <tzezula@netbeans.org> Log: #196669:Dragging and dropping very large HTML table into PHP Web Page makes IDE unresponsive verified Product Version: NetBeans IDE 7.1 RC2 (Build 201111302200) Java: 1.7.0_02; Java HotSpot(TM) Client VM 22.0-b10 System: Linux version 3.0.0-13-generic-pae running on i386; UTF-8; en_US (nb) Created attachment 118272 [details]
Screenshot after sometime (tried to maximize and restore window first, so controls disapeared)
I've got it while I was doing a sanity test for 7.1.2:
Product Version: NetBeans IDE 7.1.2 (Build 201204101705)
Java: 1.7.0_04; Java HotSpot(TM) 64-Bit Server VM 23.0-b21
System: Mac OS X version 10.7.3 running on x86_64; US-ASCII; el_GR (nb)
Took too much time to finish (netbeans was frozen), messed up the rendering and consumed tons of RAM.
Closed netbeans, reopened and tried to make it happen again, this time running the profiler to submit a snapshot, but it never became usable again to get the file. I tried to quit netbeans, but it didn't terminate, so I forced quit.
The table I tried to add had 1000 rows / 200 columns.
I usually try sizes like 500x200 which works fine (takes about 7s but that is understandable). I'm not sure how much is generating such a huge table in static HTML a "real-world" scenario (even the 500x200 generates over 100k lines!)... Can you generate the 500x200 table? Created attachment 118274 [details]
another screenshot
500x200 Works (it takes some time)
But 1000x200 works on:
Product Version: NetBeans IDE 7.1 (Build 201112051121)
Java: 1.6.0_31; Java HotSpot(TM) 64-Bit Server VM 20.6-b01-415
(after upgrade to 7.1.2).
It becomes very slow - in the limits of unusable, but at least it works. So there is a small difference in performance, even if it's not realistic. Check screenshot. I think it's an issue of what Java SDK I use (when I upgraded 7.1 to 7.1.2 it was still using the old Java SDK).
I don't even know if it matters as an issue, as it is unrealistic.
I agree, not very realistic case. I would change it to P4 if you wouldn't mind. Also you've changed "Assigned To" to yourself. If it was by mistake can you change it back please? I don't even know how I did that :p Perhaps it happened because I reopened? Of course I agree for P4, or even closing it, but I had to report it :) (In reply to comment #28) > I agree, not very realistic case. I would change it to P4 if you wouldn't mind. > Also you've changed "Assigned To" to yourself. If it was by mistake can you > change it back please? BTW I've recently added a warning to the create table dialog if one tries to create a table with 10000 cels or bigger. Thanks, I noticed the red msg but didn't know when exactly it appears so are you saying you found it not unintuitive or confusing? The message should appear once you modify the rows and columns input fields so rows multiplied by columns is bigger than 100*100. (In reply to comment #32) > so are you saying you found it not unintuitive or confusing? The message should > appear once you modify the rows and columns input fields so rows multiplied by > columns is bigger than 100*100. No, it's clear. Maybe a small modification: You can generate table that has 0 rows and more than 100000 columns and in that case <thead> (and in future maybe also tfoot) is still generated but the warning is not shown . So solution would be either alter the sum to be able to handle 0 rows or not to generate thead if number of rows is 0. In my opinion first solution would be better, some may use it to statically generate header/footer and use some code (js, php, template specific...) between to generate the real content. vlado, change the code so it handles the situation you mention. To me it seems a P6, so I consider the issue as fixed. (In reply to comment #34) > vlado, change the code so it handles the situation you mention. To me it seems > a P6, so I consider the issue as fixed. OK :) Thanks main #35bdafe70c9b Integrated into 'main-golden', will be available in build *201204190400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/35bdafe70c9b User: Vladimir Riha <vriha@netbeans.org> Log: #196669 - warning for cornes case with 0 rows I do thank you! *** Bug 205369 has been marked as a duplicate of this bug. *** |