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,  <d...@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,  <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
>
>

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

Reply via email to