You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Eelco Hillenius <ee...@gmail.com> on 2007/06/07 21:57:38 UTC
line precise error reporting: should this be on by default?
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
Re: line precise error reporting: should this be on by default?
Posted by Eelco Hillenius <ee...@gmail.com>.
I already implemented it.
Cheers!
Eelco
On 6/7/07, Martijn Dashorst <ma...@gmail.com> wrote:
> On 6/7/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > Until we find a usecase for the creation of the stack elements at a
> > > later stage, I'm fine with killing the metadata for now. We have the
> > > ability for keeping it, so it is easily re-instated.
> >
> > That sounds good to me. Do you want to implement it?
>
> Sure, will see if I get to it tomorrow. I'll definitely fix it before
> beta 2 (unless someone else builds beta 2 before me)
>
> Martijn
>
> --
> Join the wicket community at irc.freenode.net: ##wicket
> Wicket 1.2.6 contains a very important fix. Download Wicket now!
> http://wicketframework.org
>
Re: line precise error reporting: should this be on by default?
Posted by Martijn Dashorst <ma...@gmail.com>.
On 6/7/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > Until we find a usecase for the creation of the stack elements at a
> > later stage, I'm fine with killing the metadata for now. We have the
> > ability for keeping it, so it is easily re-instated.
>
> That sounds good to me. Do you want to implement it?
Sure, will see if I get to it tomorrow. I'll definitely fix it before
beta 2 (unless someone else builds beta 2 before me)
Martijn
--
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org
Re: line precise error reporting: should this be on by default?
Posted by Eelco Hillenius <ee...@gmail.com>.
> Until we find a usecase for the creation of the stack elements at a
> later stage, I'm fine with killing the metadata for now. We have the
> ability for keeping it, so it is easily re-instated.
That sounds good to me. Do you want to implement it?
Eelco
Re: line precise error reporting: should this be on by default?
Posted by Martijn Dashorst <ma...@gmail.com>.
On 6/7/07, Eelco Hillenius <ee...@gmail.com> wrote:
> The memory footprint is bothering me way more than the performance hit
> is tbh. I would be ok with keeping this if we clear it after
> rendering.
Another option might be to see if the stack trace could be compressed.
I now keep the string representation of the filtered stack (not the
complete stack trace). For instance, we could try to discover only
filename + line number, or something similar.
However, I think the number of components on your page is actually the
biggest denominator here.
Until we find a usecase for the creation of the stack elements at a
later stage, I'm fine with killing the metadata for now. We have the
ability for keeping it, so it is easily re-instated.
Martijn
--
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org
Re: line precise error reporting: should this be on by default?
Posted by Eelco Hillenius <ee...@gmail.com>.
The memory footprint is bothering me way more than the performance hit
is tbh. I would be ok with keeping this if we clear it after
rendering.
Eelco
On 6/7/07, Martijn Dashorst <ma...@gmail.com> wrote:
> 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 <ee...@gmail.com> 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
>
Re: line precise error reporting: should this be on by default?
Posted by Martijn Dashorst <ma...@gmail.com>.
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 <ee...@gmail.com> 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
Re: line precise error reporting: should this be on by default?
Posted by Eelco Hillenius <ee...@gmail.com>.
> besides the fix you've implemented by clearing this metadata
> as soon as you can, you could also make the inspector temporarily
> null it out while it computes the size of things. then the inspector
> would give you results more in line with production sizes.
The results should be good now for everything but the inspector page
(which is still rendering, but the others are done).
Eelco
Re: line precise error reporting: should this be on by default?
Posted by Jonathan Locke <jo...@gmail.com>.
besides the fix you've implemented by clearing this metadata
as soon as you can, you could also make the inspector temporarily
null it out while it computes the size of things. then the inspector
would give you results more in line with production sizes.
Eelco Hillenius 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
>
>
--
View this message in context: http://www.nabble.com/line-precise-error-reporting%3A-should-this-be-on-by-default--tf3886097.html#a11021049
Sent from the Wicket - Dev mailing list archive at Nabble.com.