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.
1) create some string property. 2) display it in TreeTableView. 3) return some big string (~500kB) as a value of this property => TreeTable is very slow while displaying it. 4) open property editor ("..." button) for it => NetBeans goes to Hollywood... (100 of CPU, not responding)
*** Issue 42111 has been marked as a duplicate of this issue. ***
This may be a dumb question, but what can a user usefully do with a 500K string property? Probably I can do something about this, but I don't see much point. Having a property sheet that supports 500K string properties is of no benefit to our users, and making it support that means spending engineering time that could be spent doing fixes users will actually benefit from ("I need an infinitely scalable property sheet" just isn't in the top 10 things we need to fix). Under what circumstances will the debugger generate a 500K string property? And why on earth are you doing that? It surely impacts the debugger's performance as well. As far as I'm concerned, the fix for this is "Don't generate 500K properties, that's a dumb thing to do." Convince me there's a valid use case here. And tell me how to reproduce the situation with the debugger in some reasonable usage scenario. Note that the problem may just be calculating the preferred size of the cell.
I do not understand your question. The described behaviour is bug, and it should be fixed. If PS is not able to deal with some large strings it should test it, and do something - throw "ToLargeStringException", display some part of string only, or... The original bug has occurred during displaying of value of some variable in debugger. We can not restrict the length of strings in user applications.
> We can not restrict the length of strings in > user applications. But you can certainly detect whether the debugger is being asked to do something crazy or not. And you certainly do know that Node.Property objects are presentation layer objects, and you can certainly detect if your Node.Property is going to return a 500K string, and truncate it, because you know in fact that the debugger has a UI, that that UI has reasonable limitations, and that in fact debuggers do not operate in a theoretical universe where all values can be infinitely large, but in a practical one where limitations exist. All of which has nothing to do with what size value the user program can return, and everything to do with the debugger placing reasonable burdens on the UI in which it runs. Do we really think somebody out there has a 4.8 kilometer wide monitor that is going to successfully display the thing? What's next, "cannot display a string longer than Integer.MAX_VALUE"? I can probably do something for the inline display of such properties, and probably make that fast. For editing them, either inline or in the custom editor, the performance characteristics will be those of JTextField and JTextArea, respectively. If they do not handle 500K of data passed into setText() well (this would not surprise me), there's nothing I can do about it. Which is exactly why this should be fixed in the debugger, NOT in the property sheet.
I do not agree: 1) You know the limits of your piece of code. I do not know the technology (and UI) used to display Strings in custom editors. You are providing some "platform". 2) You can check the limits on one place, and do some correct things... Otherwise we should check limits on many places in modules code. 3) You can deal somehow with large files. Why you do not use NetBeans editor? BTW what is the limit?
Fixed in trunk - performance should be reasonable now. Tested with both property sheet and property panel. Note that word/line wrap is now off in the custom editor for huge strings - usage of JTextArea.setText() + word/line wrap for this simply doesn't scale. A custom implementation of javax.swing.text.Document (such as the new output window uses) could work, but is hardly justified. C:\space\nb_all\core\src\org\netbeans\beaninfo\editors>cvs commit - m "#44152 Performance problems when debugger produces >512K long strings, part 1" cvs commit: Examining . Checking in StringCustomEditor.java; /cvs/core/src/org/netbeans/beaninfo/editors/StringCustomEditor.java,v <-- StringCustomEditor.java new revision: 1.26; previous revision: 1.25 done Checking in StringEditor.java; /cvs/core/src/org/netbeans/beaninfo/editors/StringEditor.java,v <-- StringEditor.java new revision: 1.20; previous revision: 1.19 done Processing log script arguments... Mailing the commit message to cvs@core.netbeans.org (from tboudreau@netbeans.org ) C:\space\nb_all\openide\src\org\openide\explorer\propertysheet>cvs commit -m "#4 4152 performance problems with >512K long strings from debugger, part 2" cvs commit: Examining . cvs commit: Examining editors Checking in PropUtils.java; /cvs/openide/src/org/openide/explorer/propertysheet/PropUtils.java,v <-- PropU tils.java new revision: 1.35; previous revision: 1.34 done Checking in RendererFactory.java; /cvs/openide/src/org/openide/explorer/propertysheet/RendererFactory.j ava,v <-- RendererFactory.java new revision: 1.13; previous revision: 1.12 done Checking in SheetTableModel.java; /cvs/openide/src/org/openide/explorer/propertysheet/SheetTableModel.j ava,v <-- SheetTableModel.java new revision: 1.5; previous revision: 1.4 done Checking in StringInplaceEditor.java; /cvs/openide/src/org/openide/explorer/propertysheet/StringInplaceEdit or.java,v <-- StringInplaceEditor.java new revision: 1.14; previous revision: 1.13 done Processing log script arguments... Mailing the commit message to cvs@openide.netbeans.org (from tboudreau@netbeans. org)
Its much better now! Thank you.