Tags
People
Badges
Help-
CORE FRAMEWORK
FEATURED COMPONENTS
-
RESOURCES
-
LEARN ZK
RESOURCES
Hi, I have started using GenericForwardComposer with ZK Calendar (<calendars>) component and I have experienced a recognizable delay, when I have access the page with the ZK Calendar first time. I suspect, the auto-wiring in not very fast. Measured times on my Dual Core @2.5GHZ:
doAfterCompose: first time (just after server starts): 391ms, next time (next time the page is accessed and the controller is cerated) 188ms
between doAfterCompose and onCreate: first time: 359ms, next time 156ms
total slow down: first time: 750ms, next time: 344ms
Moreover, the "nexttime" total processing time shown by the Firebug is about 490ms, so 344/490 = 70% of the processing time taken by the auto-wiring.
I think these times are too high. The auto-wiring (and addForwards, too) should be optimized.
Thanks, Simon and Tom. I have added a notice in Performance Tip.
I have been suggesting to disable zscript variable lookup by default, because not very experienced programmer of ZK may create zscript in the ZUL very easily, e.g. by <checkbox ... onCheck="button.setDisabled(!self.isChecked)" />.
May this change be in the ZK.3.6.5, too? But it is not very important to me, I just have one more reason to take a special care not to use zscript in the production.
Hi all,
Tom has implemented this feature in 5.0.3. You can refer to the comment in this feature request.
@xmedeko: Thanks for all the information you provided. Base on our investigation, the time spent on auto-wiring also depends on the depth of idspaces, how many components you have in each idspaces (as it tries to get from fellows too), the speed of bean shell, and also variable resolvers if any. I will keep monitering this issue, and I will get back to this thread if I discover more details.
Thanks,
Simon
@Simon: Does not matter, how much zcript is in my code, even a single zscript line:
<zscript>String str = "x";</zscript>
Also, I am including the calendar by the <include id="mainInclude"> element. When I reload the calendar, then I just call mainInclude.invalidate(); Then I see bigger the difference in the loading time (in the Firebug), because just the calendars.zul is loaded (no CSS, images, etc. ...).
@Simon: I have not wired ZScript variables, I have wired ZK components (<button id="..."). The point of this thread is, that just a few people need ZScript variables wiring. When I have disabled it, the wiring time has dropped to 0ms. So, even your 10ms is a long time. I think you have reproduced the issue well. Also, the afterCompose is not the only place, where the autowiring is performed, see my previous post: "The first call is made by doAfterCompose method, while the second one by BeforeCreateWireListener hook." Or, place timestamp measures around Components.Wire.myWireVariables(Object) method:
long time = System.currentTimeMillis();
...
System.out.println("myWireVariables time: " + (time - System.currentTimeMillis()));
@xmedeko,
Somehow I haven't found a way to reproduce this issue. I'm working ZK 3.6.4, Tomcat 6.0, Eclipse w/ JRE 6, Win XP.
I simply put timestamps around super.doAfterCompose() in the GenericForwardComposer that a canlendars applies to, which wires a few variables from zscript, but it always takes less than 10ms.
I think there must be something that I overlooked. Can I ask some questions about your test cases?
For example, how many variables do you wire from zscript? What kinds of variables?
BTW, if you can provide your test case it will be a great help. I am going to try more things to get this issue reproduced.
Simon
@Tom Just use GenericForwardComposer with your ZK Calendar (version 1.0) demo: <calendars apply="..." >. Yeah, you are right, if there's no zscript in the ZUL, the slow down is not measurable on my hardware.
IMHO it would be nice it the code would be optimised anyway. I think the zscript autowiring should be disabled by default. But there are some other places in the code, which could be tuned up a little.
Don't jump to the conclusion too fast.
From xmedeko's observation, getZScriptVariable seems slow. However, it depends on several things such as variable resolvers, the depth of ID spaces (a ID space is associated with a BeanShell scope) and so on. According to my understanding of BeanShell, it uses a map to maintain variables, and it is supposed to be fast. And, my experience of using zscript is not really slow (as least not as slow as measurable -- unless a big loop exists).
@Ondrej, did you use any variable resolver? if so, can you turn it off first to check the performance?
@Peter, there is no need to disable the check of the variable. If it is an issue, just don't use zscript at all. It is called only if an interpreter is loaded (i.e., zscript is used). In additions, it will cause some semantic issue .
@Simon, would you take a closer look and do some experiments?
I would be happy too, 'cause i don't need ZScript vars.
>> Simon, I hope some solution how to disable ZScriptVariables lookup will appear in the next release of ZK.
+1
/Robert
Asked: 2010-05-31 04:08:14 +0800
Seen: 1,119 times
Last updated: Jun 09 '10
