i don't think it will affect performance that much but it will increase memory consumption a bit
and then on both sides with that i mean the static heap (because your html size is bigger in the markup cache)
and the garbage created because the wicket id's can be used to generate urls
See Component.getPath() implementation for that.
So in the end you create a little more garbage (the response buffer) and the html pages to the client can be bigger
and uglier.
But to say that that would be a thing you can really measure.. I dont think so.
(or you must have very big id's everywhere that the page is almost twice the size :))
but that is only the rendering/response part. The request part when a repsonse comes in we need
to walk the component path
verylongverylongverylongverylong1:verylongverylongverylongverylongverylong2:verylongverylongverylongverylongverylong3:verylongverylongverylong4
so first we have to split that then compare it with a component. String compare is also pretty quick because it runs ofcourse only over the shortest string
and if the first char is already different it already know what it can return.. Only a hit (or near hit) has to walk over the completely string
But that is the penalty you get of long id's also again i dont think you will notice it. if your wicket id's are 5 or 15 chars. That is just still nothing..
But we do have a url compressor build in in wicket:
wicket.protocol.http.request.urlcompressing.URLCompressor
and
wicket.protocol.http.request.urlcompressing.WebURLCompressingTargetResolverStrategy
By using those we don't generate the full path for urls. We only map the component to a uid.
and when the request comes in we don't have to parse and walk the full component path because we just lookup the component directly for that uid.
But ofcourse this does cost some additional memory for registering that stuff..
johan
On 9/22/06, Manuel Barzi <
[EMAIL PROTECTED]> wrote:
Sirs,
Trying to get all WebPages and inner components correctly and
univocally identified (wicket:id), I am using landing in a domain of
long-named wicket:ids as, for instance, "CaocAdminPage-checkg-1", to
identify a CheckGroup...
My question is: does long-named wicket:ids affect performance, or
there's an inner wicket's optimization strategy mapping them to
faster-inner-numerical ids?
Thanks.
(May Johan Compagner answer this... ;)
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
