Well, your last round of testing said that it was 2.5x slower, so that's what my comment was based on. I haven't done any testing myself, and ww1.4 had more optimisations done to the VS after your testing.

Patrick Lightbody wrote:

Significantly faster would also be a bit incorrect. WebWork 2 is faster
than 1.4 in the area of raw EL support (math, boolean statements, etc).
It is about 50% slower than WebWork 1.4 whenever the ValueStack is
involved (which is almost all the time), which is something we indeed to
look in to as a final piece of work before 2.0 final goes out.

Daniel, are you using beta 2 (or later)? Until beta 2, the VS was about
6X slower than it is now due to a bug.

Pat

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Hani Suleiman
Sent: Thursday, January 08, 2004 8:46 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Xwork/WebWork2 under extreme load

The threadlocal issue is a red herring, ww1 uses it and it's significantly faster than ww2.

Daniel Pfeifer wrote:


That might be slightly off-topic, but it fits to the subject. However,


personally I think that webwork is quite slow once you do some serious


work with it. We are testing a webwork-based website on a P4 3Ghz plus

1


gig of RAM and some requests really do take ages (especially when the ValueStack is involved) to complete. I hope you find some ways to improve it before WW2 goes final.

/Daniel

-----Original Message-----
From: Patrick Lightbody [mailto:[EMAIL PROTECTED]
Sent: den 8 januari 2004 17:10
To: [EMAIL PROTECTED]
Subject: RE: [OS-webwork] Xwork/WebWork2 under extreme load


Well, about a year ago when we had the initial XW meetings, it was decided to keep the TL for now. Maybe post-2.0 we'll find ways to

slowly


migrate away from it. I agree though, ThreadLocals suck ass.

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Scott Farquhar
Sent: Wednesday, January 07, 2004 6:00 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Xwork/WebWork2 under extreme load

On Wed, Jan 07, 2004 at 11:56:28PM +0100, Jens Riboe wrote:
> What was the design rationale for putting it in thread local

storage?


>
> This works for servlets, but it may cause mysterious bugs in Swing
> applications, every time one uses a worker thread for a time

consuming


> UI event.
>
> How about putting state info, like actionCtx, config, etc into
> a single XWork object and then let the impl choose to store it
> appropriately. The ctx can then be created from that object.
>
> For a servlet one can use thread-based singleton, like above
> or put it into the servletCtx, and the actionCtx can be created and
stored
> into the request.
>
> For a Swing app, it generally suffice to go for a classloader
singleton,
> aka static variable, for both config and actionCtx.

I like the way that PicoContainer has done it:

public interface ObjectReference {
   Object get();

   void set(Object item);
}

Then there can be a ThreadLocalObjectReference, or a
SingletonObjectReference as needed.

I've needed to change the way that things are stored in Pico, and it

was


a 5 line change due to this abstraction.

So you have the ActionContext take an ObjectReference of where to

store


itself?

Cheers,
Scott


------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork


------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork





-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork


------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork




------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Reply via email to