> I realize it may not be a hotspot but, intuitively at least, it sounds like
> your new caching improvement will help reduce CPU load. It should also reduce
> the workload of the garbage collector by not having, in the above example,
> 2800 objects allocated and then dereferenced with every page render.
Don't trust intuition, measure. CPUs and garbage collectors behave different
then you might think.
Introducing caching means introducing thread collaboration. Any synchronisation
on modern cpus quickly take more time then any business processing you can
program. In addition, short lived object cost nothing. The gc can easily handle
millions per second.
In other words: don't add caching unless you are willing to measure the
throughput gains (on the intended target systems).
Regards,
Erik.
--
Erik van Oosten
http://day-to-day-stuff.blogspot.com
Op 17 okt. 2011, om 22:06 heeft Chris Colman het volgende geschreven:
>> We have already discussed this problem before.
>> I agree that caching will improve the performance and I'll try to
>> implement it soon.
>
> Cool!
>
>> Topicus' (Martijn's daily job) biggest application have ~ 700 mounted
>> pages and this code is not a hotspot for them, that's why no one spend
>> time on optimizing it so far.
>
> Wow that's big! If you had a variety of main and side bar menus on each page
> that had links to say 40 or so Bookmarkable pages that would mean each page
> render would result in building 40 weight/mount pair collections, each with
> 700 entries - and then throwing them away after each bookmarkable page link
> has been created.
>
> I realize it may not be a hotspot but, intuitively at least, it sounds like
> your new caching improvement will help reduce CPU load. It should also reduce
> the workload of the garbage collector by not having, in the above example,
> 2800 objects allocated and then dereferenced with every page render.
>
>>
>> On Sun, Oct 16, 2011 at 1:27 PM, Chris Colman
>> <chr...@stepaheadsoftware.com> wrote:
>>> I'll try to get some time to build a test to get some timings.
>>>
>>>> -----Original Message-----
>>>> From: Jeremy Thomerson [mailto:jer...@wickettraining.com]
>>>> Sent: Sunday, 16 October 2011 11:55 AM
>>>> To: users@wicket.apache.org
>>>> Subject: Re: Efficiency of 1.5 MountMapper weighted/matching algorithm
>>>>
>>>> On Sat, Oct 15, 2011 at 8:28 PM, Chris Colman
>>>> <chr...@stepaheadsoftware.com>wrote:
>>>>
>>>>> Obviously this isn't a problem during debug with a single user but
>>> when
>>>>> 1000s of pages need to be rendered each minute the time spent
>>> performing
>>>> the
>>>>> above operations may become significant. I haven't done any benchmark
>>>>> testing but from experience, the frequenct allocation and compiling
>>> of
>>>>> collections and sorting can get CPU expensive and switching to a
>>> caching
>>>>> alternative usually leads to significant performance
>>> improvements.****
>>>>>
>>>>>
>>>> It'd definitely be worth optimizing if we can prove it's a bottle-neck.
>>>> But
>>>> we try to avoid premature optimization. Can you put together some
>>> numbers
>>>> to see what kind of processing load we're talking about? I'd be
>>> interested
>>>> in seeing % of overall processing time under load. Something like
>>> "with X
>>>> clients browsing Y pages per minute, each page render took an average R
>>>> milliseconds, and Z milliseconds of this was in creating link URLs".
>>> Or
>>>> something like that.
>>>>
>>>> --
>>>> Jeremy Thomerson
>>>> http://wickettraining.com
>>>> *Need a CMS for Wicket? Use Brix! http://brixcms.org*
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
