Actually, the metadata could be removed at the end of the request, or as part of the render check (at a cost of processing time), so the memory footprint would not be noticable after the first render. The effect on the performance is not mitigated with that.
The metadata currently is not cleared, so that it could be used in other exceptions as well, but that is not implemented. Possibly we could also profile the construction of the stack elements, to see how it can be improved. Currently I create stacks for both the construction *and* the addition to the component hierarchy. Maybe that is overkill? Martijn On 6/7/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Hi, I'd like to discuss the recent introduced functionality of line precise error reporting - this time specifically in it's own thread. It is a new facility that records the stack trace when a component is created and when it is added to a container. A relevant representation of the stack trace (a couple of lines) is saved as meta data on the component. It is used when you created and added a component, but fail to reference it in the right place in your markup. For example, if I remove the reference in HelloWorld.html from wicket-examples, I get an exception like: WicketMessage: The component(s) below failed to render. A common problem is that you have added a component in code but forgot to reference it in the markup (thus the component will never be rendered). 1. [Component id = message, page = org.apache.wicket.examples.helloworld.HelloWorld, path = 0:message.Label, isVisible = true, isVersioned = false] The label with id 'message' that failed to render was constructed at org.apache.wicket.examples.helloworld.HelloWorld.<init>(HelloWorld.java:35) The label with id 'message' that failed to render was added at org.apache.wicket.examples.helloworld.HelloWorld.<init>(HelloWorld.java:35) This is all nice, but comes at a price: slower execution and more memory consumption. If this was just a little bit, I wouldn't be too worried. However, in the project I'm working on, the slowdown is definitively noticable, and the memory consumption is too. For example, some of our heavier pages: deployment -> development 25.1K -> 680.1K 82.7K -> 1.7M 47.3K -> 814.6K 37.2K -> 644.8K This is not a small difference, and I'm really wondering whether it is a good idea to do this by default. I find it personally anoying that the inspector pages (which I use regularly) don't give me the right information anymore. And for Wicket in general, I fear that people won't be aware of this difference (no matter how loud we shout out, most people will just miss this unless they experience a problem) and think Wicket is slow and consumes a lot of memory. I would prefer to keep this alive as a separate setting (note that it is now folded in with the IDebugSettings#componentUseCheck setting) and not have it on by default. WDYT? Eelco
-- Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
