Hi Stephane, 1) I would be surprised if there would be a significant performance improvement, but you never know until you try with these things.
There was some work Finn did have the controls render directly to the Velocity Writer, which had some significant performance improvements. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, I wanted to see if the Renderable[1] interface in velocity 1.6 could be used to improved performance in click. And indeed it can! I have made a quick and dirty hack that makes click-bench CLICK test perform more than 40% faster. From 567 to 839 request per second (average of 3 run after 1 discarded warm up run). The patch can be found here: http://people.apache.org/~bckfnn/renderable.patch.txt The patch add Renderable to our Control interface and an implementation of the interface in AbstractControl that uses an implementation of HtmlStringBuffer that writes directly to the output writer. It also changes the Decorator interface: - public String render(Object object, Context context); + public void render(Object object, Context context, HtmlStringBuffer buffer); so that columns can be written directly to the table's buffer. The drawback of the patch are: * Direct dependency on velocity * Changes to the Decorator interface. I think the Decorator change can be made backward compatible by adding a fast Decorator2 interface and eventually deprecating the slower Decorator interface. The dependency on velocity.jar is IMO acceptable for such a large performance gain. The patch contains some unused code in VelocityTemplateService that tries to avoid the dependency of velocity.jar, and while it improves performance of the CLICK test, it makes the CLICK+velocity test slower due to the overhead of registrring a ReferenceInsertionEventHandler in velocity. regards, Finn [1] http://velocity.apache.org/engine/releases/velocity-1.6.4/apidocs/org/apache/velocity/runtime/Renderable.html http://people.apache.org/~bckfnn/renderable.patch.txt <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 2) No I haven;t done anything with MVEL for templating. 3) Yes we would be interested. I am also interested in replacing OGNL with MVEL in Click. regards Malcolm Edgar On Thu, Oct 13, 2011 at 11:02 AM, stephane <[email protected]> wrote: > Hi All, > > We've been using click for some time now and I really feel it's a very good > web > framework (I've mainly used jsp, strusts and jsf before). it gets the job done > quickly and it puts some fun back in developing web app! > > Some background information: > > So far we have been using velocity template and are please with the result, > including its performance. > However, we are performance nuts over here and try to squeeze performance > boosts > whenever it's possible. We have been using MVEL (not the template part) > on others projects and found that it's faster others EL engines (ognl, > juel...). > > So here are the questions;) : > > 1) Do you guys thing that we'll get significant performance boost if we > implement > a template service using MVEL instead of the regular velocity one? > > 2) Is there anyone that has started some work in that direction > (even if it's not complete) > > 3) If we implement the MVEL template service, are you guys interested if we > contribute it back to apache click? > > all the best, > > Stephane > > > >
