You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by de...@agentlab.de on 2010/02/17 19:08:10 UTC
Large number components and redering time
Hi,
I have a question on how to address a certain problem that arose in my current
project: we have a two-dimensional array with a variable number of rows and columns
(not exactly rocket science, I know) that needs to be rendered in an HTML table where
each cell is currently represented by a wicket-Label. Now, in the production
environment, the number of rows and columns gets quite large such that we have roughly
25.000 cells to render. This yields to the effect, that the rendering process for the
component tree takes a lot of time: on my windows machine approx 7 seconds and, for
some reason we have not found out about until now, on the integration machine (IBM
server) around 45 seconds. Clearly, this is not acceptable.
Now, my question is, how should we address this problem? Is the naive approach of
using two nested ListViews and rendering each as component plain dumb? What would be
the alternatives?
Thanks for any help,
J.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Large number components and redering time
Posted by de...@agentlab.de.
I set up a WicketTester Testcase and used Eclipse TPTP to look into the
app. Over 90% were spent in beforeRender calls... However, since the load
that was produced by running the testcase within a monitored environment
brought my computer to its knees, I will have to dwell deeper into the
problem using other tools than eclipse TPTP...
J.
Martin Makundi wrote:
> Hi!
>
> Did you jprofile where the time is spent?
>
> **
> Martin
>
> 2010/2/17 <de...@agentlab.de>:
>> Hi,
>>
>> I have a question on how to address a certain problem that arose in my
>> current
>> project: we have a two-dimensional array with a variable number of rows and
>> columns
>> (not exactly rocket science, I know) that needs to be rendered in an HTML
>> table where
>> each cell is currently represented by a wicket-Label. Now, in the production
>> environment, the number of rows and columns gets quite large such that we
>> have roughly
>> 25.000 cells to render. This yields to the effect, that the rendering
>> process for the
>> component tree takes a lot of time: on my windows machine approx 7 seconds
>> and, for
>> some reason we have not found out about until now, on the integration
>> machine (IBM
>> server) around 45 seconds. Clearly, this is not acceptable.
>>
>> Now, my question is, how should we address this problem? Is the naive
>> approach of
>> using two nested ListViews and rendering each as component plain dumb? What
>> would be
>> the alternatives?
>>
>> Thanks for any help,
>>
>> J.
>>
>>
>>
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Dr. Jürgen Lind
www.agentlab.de
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Large number components and redering time
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
Hi!
Did you jprofile where the time is spent?
**
Martin
2010/2/17 <de...@agentlab.de>:
> Hi,
>
> I have a question on how to address a certain problem that arose in my
> current
> project: we have a two-dimensional array with a variable number of rows and
> columns
> (not exactly rocket science, I know) that needs to be rendered in an HTML
> table where
> each cell is currently represented by a wicket-Label. Now, in the production
> environment, the number of rows and columns gets quite large such that we
> have roughly
> 25.000 cells to render. This yields to the effect, that the rendering
> process for the
> component tree takes a lot of time: on my windows machine approx 7 seconds
> and, for
> some reason we have not found out about until now, on the integration
> machine (IBM
> server) around 45 seconds. Clearly, this is not acceptable.
>
> Now, my question is, how should we address this problem? Is the naive
> approach of
> using two nested ListViews and rendering each as component plain dumb? What
> would be
> the alternatives?
>
> Thanks for any help,
>
> J.
>
>
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Large number components and redering time
Posted by Juha Palomäki <ju...@gmail.com>.
If you want to avoid mixing HTML and Java, you could write your
component with using a templating engine, such as Velocity or
Freemarker.
I believe there is wicket-velocity project somewhere that provides for
example Panels that can render Velocity templates files.
br, Juha
On Thu, Feb 18, 2010 at 9:22 AM, <de...@agentlab.de> wrote:
> Hi,
>
> Igor Vaynberg wrote:
>>
>> i would imagine you would have the same problem even in a local
>> environment such as swing...
>
> absolutely, I was just wondering what would be the best way to do it in
> Wicket...
>
>> the solution is quiet simple, instead of using wicket components to
>> model the table and the cell simply use a single component that writes
>> out html for the entire table.
>
> That's the solution a friend of mine suggested as well since he had similar
> problems in ZK. I was reluctant since writing out HTML felt somewhat
> un-wicket-ish. But I think that's the way to go for this kind of
> situation...
>
> Thanks everybody for your suggestions and comments.
>
> J.
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Large number components and redering time
Posted by de...@agentlab.de.
Hi,
Igor Vaynberg wrote:
> i would imagine you would have the same problem even in a local
> environment such as swing...
absolutely, I was just wondering what would be the best way to do it in
Wicket...
> the solution is quiet simple, instead of using wicket components to
> model the table and the cell simply use a single component that writes
> out html for the entire table.
That's the solution a friend of mine suggested as well since he had similar
problems in ZK. I was reluctant since writing out HTML felt somewhat
un-wicket-ish. But I think that's the way to go for this kind of situation...
Thanks everybody for your suggestions and comments.
J.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Large number components and redering time
Posted by bh...@actrix.gen.nz.
Many thanks. I like it. Good when memory is expensive :)
On Wed, 17 Feb 2010 16:21:16 -0800, you wrote:
>we already provide support for all this...
>
>class cheaprenderer implements ilinklistener {
>
> protected void oncomponenttagbody(...) {
> ...
> getresponse.write("href=\"");
> getresponsr.write(urlfor(this, ilinklistener.interface)+"&x="+x+"&y="+y));
> ....
> }
>
> public final void onclick() {
> onclick(getrequest().getparameter("x"), getrequest().getparameter("y"));
> }
>
> protected abstract void onclick(int x, int y) ;
>}
>
>-igor
[snip]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Large number components and redering time
Posted by Igor Vaynberg <ig...@gmail.com>.
we already provide support for all this...
class cheaprenderer implements ilinklistener {
protected void oncomponenttagbody(...) {
...
getresponse.write("href=\"");
getresponsr.write(urlfor(this, ilinklistener.interface)+"&x="+x+"&y="+y));
....
}
public final void onclick() {
onclick(getrequest().getparameter("x"), getrequest().getparameter("y"));
}
protected abstract void onclick(int x, int y) ;
}
-igor
On Wed, Feb 17, 2010 at 4:03 PM, <bh...@actrix.gen.nz> wrote:
> In case of repeated buttons I think I would use a combination of a
> TableCellEditor and a TableCellRenderer with a button behind them,
> still only single instances serving many rows. There would only be a
> single event listener that would check selected row index. Would it
> make sense to have that in Wicket in the future? Might save a lot of
> memory.
>
> If on the other hand this button would be only needed on specific
> cells, not the pure repeater scenario, then of course one would use
> simple button instances per cell as there would not be a significant
> memory saving.
>
> On Wed, 17 Feb 2010 13:37:01 -0800, you wrote:
>
>>On Wed, Feb 17, 2010 at 1:31 PM, <bh...@actrix.gen.nz> wrote:
>>> Swing uses a variety of TableCellRenderer on a per table instance
>>> basis.
>>
>>if you had a table cell that needed a button then you wouldnt use a renderer....
> [snip]
>>
>>-igor
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Large number components and redering time
Posted by bh...@actrix.gen.nz.
In case of repeated buttons I think I would use a combination of a
TableCellEditor and a TableCellRenderer with a button behind them,
still only single instances serving many rows. There would only be a
single event listener that would check selected row index. Would it
make sense to have that in Wicket in the future? Might save a lot of
memory.
If on the other hand this button would be only needed on specific
cells, not the pure repeater scenario, then of course one would use
simple button instances per cell as there would not be a significant
memory saving.
On Wed, 17 Feb 2010 13:37:01 -0800, you wrote:
>On Wed, Feb 17, 2010 at 1:31 PM, <bh...@actrix.gen.nz> wrote:
>> Swing uses a variety of TableCellRenderer on a per table instance
>> basis.
>
>if you had a table cell that needed a button then you wouldnt use a renderer....
[snip]
>
>-igor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Large number components and redering time
Posted by Igor Vaynberg <ig...@gmail.com>.
On Wed, Feb 17, 2010 at 1:31 PM, <bh...@actrix.gen.nz> wrote:
> Swing uses a variety of TableCellRenderer on a per table instance
> basis.
if you had a table cell that needed a button then you wouldnt use a renderer....
> What component are you suggesting to use for this behavior in
> Wicket?
a simple WebComponent that writes the table as an html string to the response.
-igor
>
> Bernard
>
> On Wed, 17 Feb 2010 11:04:09 -0800, you wrote:
>
>>i would imagine you would have the same problem even in a local
>>environment such as swing...
>>
>>the solution is quiet simple, instead of using wicket components to
>>model the table and the cell simply use a single component that writes
>>out html for the entire table.
>>
>>-igor
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Large number components and redering time
Posted by bh...@actrix.gen.nz.
Swing uses a variety of TableCellRenderer on a per table instance
basis. What component are you suggesting to use for this behavior in
Wicket?
Bernard
On Wed, 17 Feb 2010 11:04:09 -0800, you wrote:
>i would imagine you would have the same problem even in a local
>environment such as swing...
>
>the solution is quiet simple, instead of using wicket components to
>model the table and the cell simply use a single component that writes
>out html for the entire table.
>
>-igor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Large number components and redering time
Posted by Igor Vaynberg <ig...@gmail.com>.
i would imagine you would have the same problem even in a local
environment such as swing...
the solution is quiet simple, instead of using wicket components to
model the table and the cell simply use a single component that writes
out html for the entire table.
-igor
On Wed, Feb 17, 2010 at 10:08 AM, <de...@agentlab.de> wrote:
> Hi,
>
> I have a question on how to address a certain problem that arose in my
> current
> project: we have a two-dimensional array with a variable number of rows and
> columns
> (not exactly rocket science, I know) that needs to be rendered in an HTML
> table where
> each cell is currently represented by a wicket-Label. Now, in the production
> environment, the number of rows and columns gets quite large such that we
> have roughly
> 25.000 cells to render. This yields to the effect, that the rendering
> process for the
> component tree takes a lot of time: on my windows machine approx 7 seconds
> and, for
> some reason we have not found out about until now, on the integration
> machine (IBM
> server) around 45 seconds. Clearly, this is not acceptable.
>
> Now, my question is, how should we address this problem? Is the naive
> approach of
> using two nested ListViews and rendering each as component plain dumb? What
> would be
> the alternatives?
>
> Thanks for any help,
>
> J.
>
>
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Large number components and redering time
Posted by de...@agentlab.de.
Granted, it is not very readable and we are investigating ways in re-defining
the requirements. But as of now, the requirements stand as they are... and I have
to find a way of meeting them...
J.
Ilja Pavkovic wrote:
> please don't tell me that there is any person around that needs 25k elements
> per page...
>
> this is a fault in the specification of the former system also :)
>
>
> Am Mittwoch, 17. Februar 2010 19:30:29 schrieb dev@agentlab.de:
>> Surely a change in the use case would ease our lives, unfortunately we are
>> migrating a legacy application to a new technology and the look and feel
>> (if you could call it that) must be retained...
>>
>> J,
>>
>> Josh Chappelle wrote:
>>> Could you use a PageableListView or does that not fall within your
>>> business requirements?
>>>
>>> Josh
>>>
>>> -----Original Message-----
>>> From: dev@agentlab.de [mailto:dev@agentlab.de]
>>> Sent: Wednesday, February 17, 2010 12:08 PM
>>> To: users@wicket.apache.org
>>> Subject: Large number components and redering time
>>>
>>> Hi,
>>>
>>> I have a question on how to address a certain problem that arose in my
>>> current
>>> project: we have a two-dimensional array with a variable number of rows
>>> and columns
>>> (not exactly rocket science, I know) that needs to be rendered in an HTML
>>> table where
>>> each cell is currently represented by a wicket-Label. Now, in the
>>> production environment, the number of rows and columns gets quite large
>>> such that we have roughly
>>> 25.000 cells to render. This yields to the effect, that the rendering
>>> process for the
>>> component tree takes a lot of time: on my windows machine approx 7
>>> seconds and, for
>>> some reason we have not found out about until now, on the integration
>>> machine (IBM
>>> server) around 45 seconds. Clearly, this is not acceptable.
>>>
>>> Now, my question is, how should we address this problem? Is the naive
>>> approach of
>>> using two nested ListViews and rendering each as component plain dumb?
>>> What would be
>>> the alternatives?
>>>
>>> Thanks for any help,
>>>
>>> J.
>>>
>>>
>>>
>>>
>>>
>>> ______________________________________________________________________
>>> This email has been scanned by the MessageLabs Email Security System.
>>> For more information please visit http://www.messagelabs.com/email
>>> ______________________________________________________________________
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Dr. Jürgen Lind
www.agentlab.de
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Large number components and redering time
Posted by Ilja Pavkovic <il...@binaere-bauten.de>.
please don't tell me that there is any person around that needs 25k elements
per page...
this is a fault in the specification of the former system also :)
Am Mittwoch, 17. Februar 2010 19:30:29 schrieb dev@agentlab.de:
> Surely a change in the use case would ease our lives, unfortunately we are
> migrating a legacy application to a new technology and the look and feel
> (if you could call it that) must be retained...
>
> J,
>
> Josh Chappelle wrote:
> > Could you use a PageableListView or does that not fall within your
> > business requirements?
> >
> > Josh
> >
> > -----Original Message-----
> > From: dev@agentlab.de [mailto:dev@agentlab.de]
> > Sent: Wednesday, February 17, 2010 12:08 PM
> > To: users@wicket.apache.org
> > Subject: Large number components and redering time
> >
> > Hi,
> >
> > I have a question on how to address a certain problem that arose in my
> > current
> > project: we have a two-dimensional array with a variable number of rows
> > and columns
> > (not exactly rocket science, I know) that needs to be rendered in an HTML
> > table where
> > each cell is currently represented by a wicket-Label. Now, in the
> > production environment, the number of rows and columns gets quite large
> > such that we have roughly
> > 25.000 cells to render. This yields to the effect, that the rendering
> > process for the
> > component tree takes a lot of time: on my windows machine approx 7
> > seconds and, for
> > some reason we have not found out about until now, on the integration
> > machine (IBM
> > server) around 45 seconds. Clearly, this is not acceptable.
> >
> > Now, my question is, how should we address this problem? Is the naive
> > approach of
> > using two nested ListViews and rendering each as component plain dumb?
> > What would be
> > the alternatives?
> >
> > Thanks for any help,
> >
> > J.
> >
> >
> >
> >
> >
> > ______________________________________________________________________
> > This email has been scanned by the MessageLabs Email Security System.
> > For more information please visit http://www.messagelabs.com/email
> > ______________________________________________________________________
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
--
binaere bauten gmbh · tempelhofer ufer 1a · 10961 berlin
+49 · 171 · 9342 465
Handelsregister: HRB 115854 - Amtsgericht Charlottenburg
Geschäftsführer: Dipl.-Inform. Ilja Pavkovic, Dipl.-Inform. Jost Becker
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Large number components and redering time
Posted by James Carman <jc...@carmanconsulting.com>.
We had some troubles like this in the past. It turned out that the
Ajax links that were in the cells were troublesome, I believe. Search
the archives. Someone gave me some code to fix it, but I don't have
it handy right now (or I don't know how to find it if I do).
On Wed, Feb 17, 2010 at 1:42 PM, <de...@agentlab.de> wrote:
> The amount of data that is generated is aroung 1MB so the time to bring it
> to
> the browser is not the problem (in a LAN setting). Also, Firebug does not
> give me
> any sign of rendering problems in the browser. Also, the large amount of
> time is
> also consumed in a WicketTester set-up without network or browser...
>
> The datastructures are lists but measuring the time for pulling the data
> from the DB
> and building the component tree shows no signs of performance issues. The
> problem does
> not occur before the actual rendering within wicket...
>
> J.
>
>
> Scott Swank wrote:
>>
>> How long does it take to pull up the static html in your browser?
>> Just the browser render can be non-trivial for a large enough file.
>>
>> Are you using arrays instead of collections and (where possible)
>> primatives instead of objects? An int[100,250] is much smaller than a
>> comparably scaled List<List<Integer>>.
>>
>> Scott
>>
>>
>> On Wed, Feb 17, 2010 at 10:30 AM, <de...@agentlab.de> wrote:
>>>
>>> Surely a change in the use case would ease our lives, unfortunately we
>>> are
>>> migrating a legacy application to a new technology and the look and feel
>>> (if
>>> you could call it that) must be retained...
>>>
>>> J,
>>>
>>> Josh Chappelle wrote:
>>>>
>>>> Could you use a PageableListView or does that not fall within your
>>>> business
>>>> requirements?
>>>>
>>>> Josh
>>>>
>>>> -----Original Message-----
>>>> From: dev@agentlab.de [mailto:dev@agentlab.de] Sent: Wednesday, February
>>>> 17, 2010 12:08 PM
>>>> To: users@wicket.apache.org
>>>> Subject: Large number components and redering time
>>>>
>>>> Hi,
>>>>
>>>> I have a question on how to address a certain problem that arose in my
>>>> current
>>>> project: we have a two-dimensional array with a variable number of rows
>>>> and
>>>> columns
>>>> (not exactly rocket science, I know) that needs to be rendered in an
>>>> HTML
>>>> table where
>>>> each cell is currently represented by a wicket-Label. Now, in the
>>>> production
>>>> environment, the number of rows and columns gets quite large such that
>>>> we
>>>> have roughly
>>>> 25.000 cells to render. This yields to the effect, that the rendering
>>>> process for the
>>>> component tree takes a lot of time: on my windows machine approx 7
>>>> seconds
>>>> and, for
>>>> some reason we have not found out about until now, on the integration
>>>> machine (IBM
>>>> server) around 45 seconds. Clearly, this is not acceptable.
>>>>
>>>> Now, my question is, how should we address this problem? Is the naive
>>>> approach of
>>>> using two nested ListViews and rendering each as component plain dumb?
>>>> What
>>>> would be
>>>> the alternatives?
>>>>
>>>> Thanks for any help,
>>>>
>>>> J.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ______________________________________________________________________
>>>> This email has been scanned by the MessageLabs Email Security System.
>>>> For more information please visit http://www.messagelabs.com/email
>>>> ______________________________________________________________________
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>> --
>>> Dr. Jürgen Lind
>>> www.agentlab.de
>>>
>>>
>>> ______________________________________________________________________
>>> This email has been scanned by the MessageLabs Email Security System.
>>> For more information please visit http://www.messagelabs.com/email
>>> ______________________________________________________________________
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> --
> Dr. Jürgen Lind
> www.agentlab.de
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Large number components and redering time
Posted by Martin Makundi <ma...@koodaripalvelut.com>.
And loadabledetachablemodels are in place?
**
Martin
2010/2/17 <de...@agentlab.de>:
> The amount of data that is generated is aroung 1MB so the time to bring it
> to
> the browser is not the problem (in a LAN setting). Also, Firebug does not
> give me
> any sign of rendering problems in the browser. Also, the large amount of
> time is
> also consumed in a WicketTester set-up without network or browser...
>
> The datastructures are lists but measuring the time for pulling the data
> from the DB
> and building the component tree shows no signs of performance issues. The
> problem does
> not occur before the actual rendering within wicket...
>
> J.
>
>
> Scott Swank wrote:
>>
>> How long does it take to pull up the static html in your browser?
>> Just the browser render can be non-trivial for a large enough file.
>>
>> Are you using arrays instead of collections and (where possible)
>> primatives instead of objects? An int[100,250] is much smaller than a
>> comparably scaled List<List<Integer>>.
>>
>> Scott
>>
>>
>> On Wed, Feb 17, 2010 at 10:30 AM, <de...@agentlab.de> wrote:
>>>
>>> Surely a change in the use case would ease our lives, unfortunately we
>>> are
>>> migrating a legacy application to a new technology and the look and feel
>>> (if
>>> you could call it that) must be retained...
>>>
>>> J,
>>>
>>> Josh Chappelle wrote:
>>>>
>>>> Could you use a PageableListView or does that not fall within your
>>>> business
>>>> requirements?
>>>>
>>>> Josh
>>>>
>>>> -----Original Message-----
>>>> From: dev@agentlab.de [mailto:dev@agentlab.de] Sent: Wednesday, February
>>>> 17, 2010 12:08 PM
>>>> To: users@wicket.apache.org
>>>> Subject: Large number components and redering time
>>>>
>>>> Hi,
>>>>
>>>> I have a question on how to address a certain problem that arose in my
>>>> current
>>>> project: we have a two-dimensional array with a variable number of rows
>>>> and
>>>> columns
>>>> (not exactly rocket science, I know) that needs to be rendered in an
>>>> HTML
>>>> table where
>>>> each cell is currently represented by a wicket-Label. Now, in the
>>>> production
>>>> environment, the number of rows and columns gets quite large such that
>>>> we
>>>> have roughly
>>>> 25.000 cells to render. This yields to the effect, that the rendering
>>>> process for the
>>>> component tree takes a lot of time: on my windows machine approx 7
>>>> seconds
>>>> and, for
>>>> some reason we have not found out about until now, on the integration
>>>> machine (IBM
>>>> server) around 45 seconds. Clearly, this is not acceptable.
>>>>
>>>> Now, my question is, how should we address this problem? Is the naive
>>>> approach of
>>>> using two nested ListViews and rendering each as component plain dumb?
>>>> What
>>>> would be
>>>> the alternatives?
>>>>
>>>> Thanks for any help,
>>>>
>>>> J.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ______________________________________________________________________
>>>> This email has been scanned by the MessageLabs Email Security System.
>>>> For more information please visit http://www.messagelabs.com/email
>>>> ______________________________________________________________________
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>> --
>>> Dr. Jürgen Lind
>>> www.agentlab.de
>>>
>>>
>>> ______________________________________________________________________
>>> This email has been scanned by the MessageLabs Email Security System.
>>> For more information please visit http://www.messagelabs.com/email
>>> ______________________________________________________________________
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> --
> Dr. Jürgen Lind
> www.agentlab.de
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Large number components and redering time
Posted by de...@agentlab.de.
The amount of data that is generated is aroung 1MB so the time to bring it to
the browser is not the problem (in a LAN setting). Also, Firebug does not give me
any sign of rendering problems in the browser. Also, the large amount of time is
also consumed in a WicketTester set-up without network or browser...
The datastructures are lists but measuring the time for pulling the data from the DB
and building the component tree shows no signs of performance issues. The problem does
not occur before the actual rendering within wicket...
J.
Scott Swank wrote:
> How long does it take to pull up the static html in your browser?
> Just the browser render can be non-trivial for a large enough file.
>
> Are you using arrays instead of collections and (where possible)
> primatives instead of objects? An int[100,250] is much smaller than a
> comparably scaled List<List<Integer>>.
>
> Scott
>
>
> On Wed, Feb 17, 2010 at 10:30 AM, <de...@agentlab.de> wrote:
>> Surely a change in the use case would ease our lives, unfortunately we are
>> migrating a legacy application to a new technology and the look and feel (if
>> you could call it that) must be retained...
>>
>> J,
>>
>> Josh Chappelle wrote:
>>> Could you use a PageableListView or does that not fall within your
>>> business
>>> requirements?
>>>
>>> Josh
>>>
>>> -----Original Message-----
>>> From: dev@agentlab.de [mailto:dev@agentlab.de] Sent: Wednesday, February
>>> 17, 2010 12:08 PM
>>> To: users@wicket.apache.org
>>> Subject: Large number components and redering time
>>>
>>> Hi,
>>>
>>> I have a question on how to address a certain problem that arose in my
>>> current
>>> project: we have a two-dimensional array with a variable number of rows
>>> and
>>> columns
>>> (not exactly rocket science, I know) that needs to be rendered in an HTML
>>> table where
>>> each cell is currently represented by a wicket-Label. Now, in the
>>> production
>>> environment, the number of rows and columns gets quite large such that we
>>> have roughly
>>> 25.000 cells to render. This yields to the effect, that the rendering
>>> process for the
>>> component tree takes a lot of time: on my windows machine approx 7 seconds
>>> and, for
>>> some reason we have not found out about until now, on the integration
>>> machine (IBM
>>> server) around 45 seconds. Clearly, this is not acceptable.
>>>
>>> Now, my question is, how should we address this problem? Is the naive
>>> approach of
>>> using two nested ListViews and rendering each as component plain dumb?
>>> What
>>> would be
>>> the alternatives?
>>>
>>> Thanks for any help,
>>>
>>> J.
>>>
>>>
>>>
>>>
>>>
>>> ______________________________________________________________________
>>> This email has been scanned by the MessageLabs Email Security System.
>>> For more information please visit http://www.messagelabs.com/email
>>> ______________________________________________________________________
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>> --
>> Dr. Jürgen Lind
>> www.agentlab.de
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Dr. Jürgen Lind
www.agentlab.de
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Large number components and redering time
Posted by Scott Swank <sc...@gmail.com>.
How long does it take to pull up the static html in your browser?
Just the browser render can be non-trivial for a large enough file.
Are you using arrays instead of collections and (where possible)
primatives instead of objects? An int[100,250] is much smaller than a
comparably scaled List<List<Integer>>.
Scott
On Wed, Feb 17, 2010 at 10:30 AM, <de...@agentlab.de> wrote:
> Surely a change in the use case would ease our lives, unfortunately we are
> migrating a legacy application to a new technology and the look and feel (if
> you could call it that) must be retained...
>
> J,
>
> Josh Chappelle wrote:
>>
>> Could you use a PageableListView or does that not fall within your
>> business
>> requirements?
>>
>> Josh
>>
>> -----Original Message-----
>> From: dev@agentlab.de [mailto:dev@agentlab.de] Sent: Wednesday, February
>> 17, 2010 12:08 PM
>> To: users@wicket.apache.org
>> Subject: Large number components and redering time
>>
>> Hi,
>>
>> I have a question on how to address a certain problem that arose in my
>> current
>> project: we have a two-dimensional array with a variable number of rows
>> and
>> columns
>> (not exactly rocket science, I know) that needs to be rendered in an HTML
>> table where
>> each cell is currently represented by a wicket-Label. Now, in the
>> production
>> environment, the number of rows and columns gets quite large such that we
>> have roughly
>> 25.000 cells to render. This yields to the effect, that the rendering
>> process for the
>> component tree takes a lot of time: on my windows machine approx 7 seconds
>> and, for
>> some reason we have not found out about until now, on the integration
>> machine (IBM
>> server) around 45 seconds. Clearly, this is not acceptable.
>>
>> Now, my question is, how should we address this problem? Is the naive
>> approach of
>> using two nested ListViews and rendering each as component plain dumb?
>> What
>> would be
>> the alternatives?
>>
>> Thanks for any help,
>>
>> J.
>>
>>
>>
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email
>> ______________________________________________________________________
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> --
> Dr. Jürgen Lind
> www.agentlab.de
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Large number components and redering time
Posted by de...@agentlab.de.
Surely a change in the use case would ease our lives, unfortunately we are
migrating a legacy application to a new technology and the look and feel (if
you could call it that) must be retained...
J,
Josh Chappelle wrote:
> Could you use a PageableListView or does that not fall within your business
> requirements?
>
> Josh
>
> -----Original Message-----
> From: dev@agentlab.de [mailto:dev@agentlab.de]
> Sent: Wednesday, February 17, 2010 12:08 PM
> To: users@wicket.apache.org
> Subject: Large number components and redering time
>
> Hi,
>
> I have a question on how to address a certain problem that arose in my
> current
> project: we have a two-dimensional array with a variable number of rows and
> columns
> (not exactly rocket science, I know) that needs to be rendered in an HTML
> table where
> each cell is currently represented by a wicket-Label. Now, in the production
> environment, the number of rows and columns gets quite large such that we
> have roughly
> 25.000 cells to render. This yields to the effect, that the rendering
> process for the
> component tree takes a lot of time: on my windows machine approx 7 seconds
> and, for
> some reason we have not found out about until now, on the integration
> machine (IBM
> server) around 45 seconds. Clearly, this is not acceptable.
>
> Now, my question is, how should we address this problem? Is the naive
> approach of
> using two nested ListViews and rendering each as component plain dumb? What
> would be
> the alternatives?
>
> Thanks for any help,
>
> J.
>
>
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
--
Dr. Jürgen Lind
www.agentlab.de
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Large number components and redering time
Posted by Josh Chappelle <jc...@4redi.com>.
Could you use a PageableListView or does that not fall within your business
requirements?
Josh
-----Original Message-----
From: dev@agentlab.de [mailto:dev@agentlab.de]
Sent: Wednesday, February 17, 2010 12:08 PM
To: users@wicket.apache.org
Subject: Large number components and redering time
Hi,
I have a question on how to address a certain problem that arose in my
current
project: we have a two-dimensional array with a variable number of rows and
columns
(not exactly rocket science, I know) that needs to be rendered in an HTML
table where
each cell is currently represented by a wicket-Label. Now, in the production
environment, the number of rows and columns gets quite large such that we
have roughly
25.000 cells to render. This yields to the effect, that the rendering
process for the
component tree takes a lot of time: on my windows machine approx 7 seconds
and, for
some reason we have not found out about until now, on the integration
machine (IBM
server) around 45 seconds. Clearly, this is not acceptable.
Now, my question is, how should we address this problem? Is the naive
approach of
using two nested ListViews and rendering each as component plain dumb? What
would be
the alternatives?
Thanks for any help,
J.
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org