Re: Slow rendering

[Martin Grigorov]

Also see org.apache.wicket.devutils.inspector.RenderPerformanceListener
in wicket-devutils module. Enable it and then check the data with the
DebugBar (org.apache.wicket.devutils.debugbar.DebugBar)

On Sat, Aug 25, 2012 at 2:58 AM, steven.li  wrote:
> Enable wicket debug log, it will show the begin render and end render time in
> log file.
>
> log4j.logger.org.apache.wicket=debug
>
>
>
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/Slow-rendering-tp4395082p4651490.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Slow rendering

[steven.li]

how to let it render lazily?



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Slow-rendering-tp4395082p4651491.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Slow rendering

[steven.li]

Enable wicket debug log, it will show the begin render and end render time in
log file.

log4j.logger.org.apache.wicket=debug



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Slow-rendering-tp4395082p4651490.html
Sent from the Users forum mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Slow rendering

[Jürgen Lind]

Hi,

thank you for your input on how to attack my problem... As it turned out,
the simplest way to see where the time is spent, was to override the
"render" method of various components. I had used "onBeginRender" and 
"onAfterRender"
before, but they seem to be called asymetrically so I was not able to to
properly associate the start and stop events for a particular timer.

To use a profiling tool was not an option since I do not have full access to the
integration testing machine and thus I cannot instrument the server. Secondly, I
wanted to measure the data on a per request basis which is - to my knowledge - 
not
possible with this kind of tools.

Long story short: the time is spent in the rendering phase for the component 
that
represents a tree entry. Due to various requirements, this component is fairly 
complex
and I takes approx. 2.5 to render one of them. Multiply by 5000 and that's it...

No comes the tricky bit: to convince our customer, that opening 5000 tree 
entries
simultaneously is not  really a good idea...

J.

On 17.02.2012 00:28, Pamir Erdem wrote:

I'm so sorry but i could not understand the question. If it is in server
side than you can instrument it with JProfiler or JxInsight.
If it is on client side dynaTrace can help you or even google chrome
javascript can help you to detect the problem

On Thu, Feb 16, 2012 at 10:42 PM, Jürgen Lindwrote:


Hi,

as I was saying in the original post, in rare cases the tree degenerates
to a plain
list - i.e a tree with one (hidden) root node and up to 5000 children that
are rendered
at the same time. Please do not ask me, why our customer would want that -
it is how
it is for the time being ;-)

J.


On 16.02.2012 21:13, Igor Vaynberg wrote:


why is your tree rendering all the nodes ahead of time? shouldnt it
render them lazily as they are expanded?

-igor

On Thu, Feb 16, 2012 at 10:50 AM, Jürgen Lind
  wrote:


Hi there,

I am currently encountering a problem that I don't know how to attack...
We
have
developed an application that uses the Tree-Component to show
hierarchical
data
to the user. In some cases, the tree degenerates to a plain list that
can be
quite
large. Now, if the list has around 1000 entries, the rendering phase for
the
tree
takes approx. 1 second, which seems to be ok. For 2500 entries, the
rendering time
goes up to around 11 seconds and with 5000 entries, we're looking at
approx.
30
seconds.

Now, I would like to find out, which part of the component tree causes
these
huge
numbers, but I have run out of ideas on how to track down these numbers.
The
last
point I was able to measure was between onBeforeRender and onAfterRender
of
my
subclassed LabelTree component.

Any suggestions on how to instrument my application without building a
custom wicket
package?

Kind Regards,

J.

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel

--**--**
-
To unsubscribe, e-mail: 
users-unsubscribe@wicket.**apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



--**--**-
To unsubscribe, e-mail: 
users-unsubscribe@wicket.**apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel

--**--**-
To unsubscribe, e-mail: 
users-unsubscribe@wicket.**apache.org
For additional commands, e-mail: users-h...@wicket.apache.org








Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Slow rendering

[Pamir Erdem]

I'm so sorry but i could not understand the question. If it is in server
side than you can instrument it with JProfiler or JxInsight.
If it is on client side dynaTrace can help you or even google chrome
javascript can help you to detect the problem

On Thu, Feb 16, 2012 at 10:42 PM, Jürgen Lind wrote:

> Hi,
>
> as I was saying in the original post, in rare cases the tree degenerates
> to a plain
> list - i.e a tree with one (hidden) root node and up to 5000 children that
> are rendered
> at the same time. Please do not ask me, why our customer would want that -
> it is how
> it is for the time being ;-)
>
> J.
>
>
> On 16.02.2012 21:13, Igor Vaynberg wrote:
>
>> why is your tree rendering all the nodes ahead of time? shouldnt it
>> render them lazily as they are expanded?
>>
>> -igor
>>
>> On Thu, Feb 16, 2012 at 10:50 AM, Jürgen Lind
>>  wrote:
>>
>>> Hi there,
>>>
>>> I am currently encountering a problem that I don't know how to attack...
>>> We
>>> have
>>> developed an application that uses the Tree-Component to show
>>> hierarchical
>>> data
>>> to the user. In some cases, the tree degenerates to a plain list that
>>> can be
>>> quite
>>> large. Now, if the list has around 1000 entries, the rendering phase for
>>> the
>>> tree
>>> takes approx. 1 second, which seems to be ok. For 2500 entries, the
>>> rendering time
>>> goes up to around 11 seconds and with 5000 entries, we're looking at
>>> approx.
>>> 30
>>> seconds.
>>>
>>> Now, I would like to find out, which part of the component tree causes
>>> these
>>> huge
>>> numbers, but I have run out of ideas on how to track down these numbers.
>>> The
>>> last
>>> point I was able to measure was between onBeforeRender and onAfterRender
>>> of
>>> my
>>> subclassed LabelTree component.
>>>
>>> Any suggestions on how to instrument my application without building a
>>> custom wicket
>>> package?
>>>
>>> Kind Regards,
>>>
>>> J.
>>>
>>> --
>>> Dr. Jürgen Lind
>>> iteratec GmbHFon: +49 (0)89 614551-44
>>> Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
>>> 82008 Unterhaching   Web: www.iteratec.de
>>>
>>> Sitz und Registergericht der iteratec GmbH: München HRB 113 519
>>> Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel
>>>
>>> --**--**
>>> -
>>> To unsubscribe, e-mail: 
>>> users-unsubscribe@wicket.**apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> users-unsubscribe@wicket.**apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> Mit freundlichen Grüßen,
>
> Jürgen Lind
>
> --
> Dr. Jürgen Lind
> iteratec GmbHFon: +49 (0)89 614551-44
> Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
> 82008 Unterhaching   Web: www.iteratec.de
>
> Sitz und Registergericht der iteratec GmbH: München HRB 113 519
> Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@wicket.**apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Pamir Erdem

Re: Slow rendering

[Jürgen Lind]

Hi,

as I was saying in the original post, in rare cases the tree degenerates to a 
plain
list - i.e a tree with one (hidden) root node and up to 5000 children that are 
rendered
at the same time. Please do not ask me, why our customer would want that - it 
is how
it is for the time being ;-)

J.


On 16.02.2012 21:13, Igor Vaynberg wrote:

why is your tree rendering all the nodes ahead of time? shouldnt it
render them lazily as they are expanded?

-igor

On Thu, Feb 16, 2012 at 10:50 AM, Jürgen Lind  wrote:

Hi there,

I am currently encountering a problem that I don't know how to attack... We
have
developed an application that uses the Tree-Component to show hierarchical
data
to the user. In some cases, the tree degenerates to a plain list that can be
quite
large. Now, if the list has around 1000 entries, the rendering phase for the
tree
takes approx. 1 second, which seems to be ok. For 2500 entries, the
rendering time
goes up to around 11 seconds and with 5000 entries, we're looking at approx.
30
seconds.

Now, I would like to find out, which part of the component tree causes these
huge
numbers, but I have run out of ideas on how to track down these numbers. The
last
point I was able to measure was between onBeforeRender and onAfterRender of
my
subclassed LabelTree component.

Any suggestions on how to instrument my application without building a
custom wicket
package?

Kind Regards,

J.

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




Mit freundlichen Grüßen,

Jürgen Lind

--
Dr. Jürgen Lind
iteratec GmbHFon: +49 (0)89 614551-44
Inselkammerstrasse 4 Fax: +49 (0)89 614551-10
82008 Unterhaching   Web: www.iteratec.de

Sitz und Registergericht der iteratec GmbH: München HRB 113 519
Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Slow rendering

[Igor Vaynberg]

why is your tree rendering all the nodes ahead of time? shouldnt it
render them lazily as they are expanded?

-igor

On Thu, Feb 16, 2012 at 10:50 AM, Jürgen Lind  wrote:
> Hi there,
>
> I am currently encountering a problem that I don't know how to attack... We
> have
> developed an application that uses the Tree-Component to show hierarchical
> data
> to the user. In some cases, the tree degenerates to a plain list that can be
> quite
> large. Now, if the list has around 1000 entries, the rendering phase for the
> tree
> takes approx. 1 second, which seems to be ok. For 2500 entries, the
> rendering time
> goes up to around 11 seconds and with 5000 entries, we're looking at approx.
> 30
> seconds.
>
> Now, I would like to find out, which part of the component tree causes these
> huge
> numbers, but I have run out of ideas on how to track down these numbers. The
> last
> point I was able to measure was between onBeforeRender and onAfterRender of
> my
> subclassed LabelTree component.
>
> Any suggestions on how to instrument my application without building a
> custom wicket
> package?
>
> Kind Regards,
>
> J.
>
> --
> Dr. Jürgen Lind
> iteratec GmbH                Fon: +49 (0)89 614551-44
> Inselkammerstrasse 4         Fax: +49 (0)89 614551-10
> 82008 Unterhaching           Web: www.iteratec.de
>
> Sitz und Registergericht der iteratec GmbH: München HRB 113 519
> Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Slow rendering

[Christian Huber]

Hi Jürgen,

I just had a quick glance at the Component and MarkupContainer classes 
and if I am not mistaken you should be able to override onRender() and 
onComponentTag() which would give you a few more measuring points and 
maybe more pointers on where to look further.


HTH, Christian


The Sanity Resort 

Am 16.02.2012 19:50, schrieb Jürgen Lind:

Hi there,

I am currently encountering a problem that I don't know how to 
attack... We have
developed an application that uses the Tree-Component to show 
hierarchical data
to the user. In some cases, the tree degenerates to a plain list that 
can be quite
large. Now, if the list has around 1000 entries, the rendering phase 
for the tree
takes approx. 1 second, which seems to be ok. For 2500 entries, the 
rendering time
goes up to around 11 seconds and with 5000 entries, we're looking at 
approx. 30

seconds.

Now, I would like to find out, which part of the component tree causes 
these huge
numbers, but I have run out of ideas on how to track down these 
numbers. The last
point I was able to measure was between onBeforeRender and 
onAfterRender of my

subclassed LabelTree component.

Any suggestions on how to instrument my application without building a 
custom wicket

package?

Kind Regards,

J.