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, <d...@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: d...@agentlab.de [mailto:d...@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-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
--
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-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
--
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-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
