Confirmed. Turn off the logging (initialise log4j and set level for
wicket to INFO or greater) and Wicket is only about 4% slower than the
Tapestry application. I suspect with a little effort we could soon tune
out this small amount :) Probably best to wait until the 1.1 code
base is complete to do this as refactorings are notorious for undoing
previous performance optimizations.
However, the question is therefore what to do with logging: One option
is to ship Wicket example applications with correctly configured log4j
to turn logging off by default. This would also require VERY clear
documentation to explain that Wicket logging should be turned off by
default due to the application performance hit of having it switched on.
Alternatively, we should just go through the code and remove all of the
debug render or at least refactor the statements of the form:
log.debug("Begin render " + this); which are very expensive because they
do a toString() on the object.
Any other thoughts?
regards,
Chris
Johan Compagner wrote:
if that really is the case then we should turn logging default off??
and supply a right properties file?
johan
Chris Turner wrote:
One word: *** LOGGING ***
Looking through the profile in detail it appears that the benchmark
application has no logging configured so by default logging is ON.
Many of the preformance bottlenecks seem to be in building the
strings for logging. I'm going to figure out how to turn off logging
and then I'll try the profiling again.
regards,
Chris
Chris Turner wrote:
I have just run the two examples through a profiler (YourKit Java
Profiler) and I can confirm that the Tapestry example is just over
twice as fast as the Wicket one. The amount of difference is
variable, with the biggest difference being for the page that
renders the list view.
Taking a quick look through the profile trace for the Wicker code
there does not seem to be any one area where there is a particular
performance bottleneck. However, most of the largest areas of
execution time resolve down to one of two cases:
- Methods that do lots of string manipulation (in particular
toString and StringBuffer.append stuff)
- Methods that invoke Ognl
Expanded report showing main bottlenecks as identified by YourKit:
http://www.skipoles.co.uk/wicket-benchmark.zip
I'll investigate a bit further.....
regards,
Chris
Eelco Hillenius wrote:
That's a scarry difference. We should take a good look at that and
see what causes it. Personally, I wouldn't expect our
'statefullness' to be the real problem here; as 'heavy' as it
sounds to create new objects, this is something Java should be very
good at. We should use a profiler to find out.
Eelco
Phil Kulak wrote:
I just did some quick testing using the two wars. I did 100 page
loads
with a brand new session on each load and Tapestry was about twice as
fast for the list view page and the much smaller edit page. I wonder
what would happen if I made the Tapestry app stateful as well. That
may be a more fair comparison.
On 7/10/05, Phil Kulak <[EMAIL PROTECTED]> wrote:
Arg, okay, that was to much to post. Here's the origonal message:
Here are the two wars. Let me know if I should change the
functionality at all. Also, notice that I didn't try very hard to
optimize the wicket application. For example, I don't use
optimizeItemRemoval = true and then manually removeAll() on
deletes. I
could have done that, but there are probably corrosponding
optimizations for Tapestry that I just don't know about because I
don't use it. Also, the Tapestry app is totally stateless, so
that may
give it an edge, but I dunno for sure.
On 7/10/05, Phil Kulak <[EMAIL PROTECTED]> wrote:
Okay, I just realized that it was a bit dumb to post 5 megs of
files
to mailing list. Sorry about that. Here are some URLs:
http://gladstone.uoregon.edu/~pkulak/tapestry-benchmark.war
http://gladstone.uoregon.edu/~pkulak/wicket-benchmark.war
On 7/10/05, Phil Kulak <[EMAIL PROTECTED]> wrote:
Here are the two wars. Let me know if I should change the
functionality at all. Also, notice that I didn't try very hard to
optimize the wicket application. For example, I don't use
optimizeItemRemoval = true and then manually removeAll() on
deletes. I
could have done that, but there are probably corrosponding
optimizations for Tapestry that I just don't know about because I
don't use it. Also, the Tapestry app is totally stateless, so
that may
give it an edge, but I dunno for sure.
-Phil
On 7/10/05, Phil Kulak <[EMAIL PROTECTED]> wrote:
If there's just one DAO, then I can store the data in a Map
and not
worry about HSQL or anything like that. Actually, I just wrote
it in
Wicket (it's absolutly frickin' amazing how FEW lines it took)
and
I'll get it cloned in Tapestry tomorrow and post up both wars.
Basicaly, it's just a bare-bones version of your CD-App. I
didn't want
to make it too complicated because I'm not super efficiant with
Tapestry and I didn't want that part to take all day.
-Phil
On 7/10/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Phil Kulak wrote:
Unless the dynamic images are actually created on the fly,
Wicket's
gonna get slaughtered there since Tapestry will actually
copy static
images from the jar into a public webserver directory.
I think Wicket handles the static images pretty efficiently.
It would be
interesting to see if there is any performance difference
with Tapestry,
but I think not. So Tapestry actually copies the resources to
the webapp
directory? A potential problem with that is that you can't be
sure that
you have write rights in your webapp dir. You can't even be
sure if
there is a filesystem dir at all (might still be a .war, or
potentially
some other schema).
Maybe a list view of 50 items with edit and delete options?
I could
make a single, thread-safe DAO, and then if you could find a
way to
hit the page a bunch of times with concurrent edits and
deletes, it
would be a nice muli-user test.
Why should you have just one DAO? Why not an instance per
request or
session?
That's my idea, but I have no idea how you plan to test it, so
something else may be more appropriate.
I think it would be nice to have a special performance test
page. Where
should we put it though?
Eelco
On 7/9/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
If i get 2 wars of an app that does some big rendering
(like listviews,
dynamic images and that kind of thing)
So i don't think hangman will do it really it is a bit to
small.
Don't know if we really have to test a database. That i
don't like. It
should be plain pojo's
that are in mem created for a list/detail/edit view.
What kind of functionality would be a good test?
johan
Phil Kulak wrote:
Is this offer still available? Don't we already have a
working Hangman
app in both frameworks? If that won't cut it, I'd be glad
to write a
Tapestry clone of a Wicket app. It would give me a chance
to get
better acquainted with Tapestry 4.
On 6/18/05, Johan Compagner <[EMAIL PROTECTED]> wrote:
then we need 2 the same apps with the same feature set in
both frameworks.
If somebody is willing to build that and supply me with the
2 wars then
i will do a performance test
with yourekit..
johan
叶卫国 wrote:
Does anybody compare it with tapestry?
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
from IBM. Find simple to follow Roadmaps, straightforward
articles,
informative Webcasts and more! Get everything you need to
get up to
speed, fast.
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration
Strategies
from IBM. Find simple to follow Roadmaps,
straightforward articles,
informative Webcasts and more! Get everything you need to
get up to
speed, fast.
http://ads.osdn.com/?ad_idt77&alloc_id492&opclick
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
N琀S^甸殜X�'矈辵辑呧�Z+a妤伶鉂j歗�)�&閞讍⿵
?跽﹦
5瀶{獾歙黑 茩hazV瓃薭澺殨�+y┹v妤偠﹩',电!瀴h�&瑍窞
、 贽 介韱�-y烛 �
┹5R
璀�"沧+"�m��鹈ir壙倧莨﹑y抚j耽rG谦櫒x%娝V壣 峨 甔
� (悍 ~娻zw瓎踚��鍔薼矉玵玷�咤娝l⺋)撸 �"rG谦
N�HS^�隊X���'���u�����2��Z+a���❪�j�^�)�&�r׆��
?�թ�
5��{�쨺� ƙh��azV�z�b�ۚ��+y��v楂���',��!��h�&��
�~���w���� 톋-y�� �
��5R
��"��+"�m����ir����ݹ�py��j��rG��ǫ����x%��V�� �� �X���(�� ~��zw���i����l���q���z���l�X��)ߣ�"rG��ǫ
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!'
webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the
latest in dual
core and dual graphics technology at this free one hour event
hosted by HP,
AMD, and NVIDIA. To register visit
http://www.hp.com/go/dualwebinar
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
N�HS^�隊X���'���u�����2��Z+a���❪�j�^�)�&�r׆��
?�թ�
5��{�쨺� ƙh��azV�z�b�ۚ��+y��v楂���',��!��h�&���~���w����톋-y�� �
��5R
��"��+"�m����ir����ݹ�py��j��rG��ǫ����x%��V�� �� �X���(�� ~��zw���i����l���q���z���l�X��)ߣ�"rG��ǫ
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar
happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in
dual
core and dual graphics technology at this free one hour event
hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar
happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in
dual
core and dual graphics technology at this free one hour event hosted
by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar
happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted
by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar
happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted
by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
