Performance in Cache ObjectScript
Hi Guys,
Can you please advise on the below queries.
Query 1:
Example 1:
S a="345",b="arun",c="kumar",d="hi",e="yello",f="orange"
Example 2:
S a="345" S b="arun" S c="kumar" S d="hi" S e="yello" S f="orange"
Can you please advise me, which one is performance wise is better.
Query 2:
Example 1:
S:a=1 R="Arun"
Example 2:
I a=2 R="Arun"
Please advise me, which one is giving better performance in this.
Any lead would be appreciated.
Thanks,
Arun Kumar Durairaj.
query 1 misses a variant:
query 2,example 2 should be
I a=2 SET R="Arun"Thanks for the query 1 new approach and correction of query2 example 2.
Thanks a ton again.
AFAIK, line terminators are no longer stored in OBJ code since version 2010.1, so splitting a long code line into smaller ones can't affect performance at all.
On my desktop quite other results.
n N,j,time s N=1e8 f j=1,2/*,3,4,5*/ { w j,") " s time=$zh d @("j"_j)(N) w $zh-time," s.",! } q j1(N) public { f i=1:1:N {s (a,b,c,d,e,f)=0} } j2(N) public { f i=1:1:N {s a=0,b=0,c=0,d=0,e=0,f=0} } j3(N) public { f i=1:1:N {s a=0,b=1,c=2,d=3,e=4,f=5} } j4(N) public { f i=1:1:N {s a=0 s b=1 s c=2 s d=3 s e=4 s f=5} } j5(N) public { f i=1:1:N {s $lb(a,b,c,d,e,f)=$lb(0,1,2,3,4,5)} }Results:
As you can see the difference is almost 2.5 times.
Query 1 Example 1 could be marginally faster by less line terminations and less command dispatch:
But as this will be compiled some kind of code optimizer eventually might run.
Query2 Example1 is faster by less line terminations and less command dispatch.
BUT: Both cases aren't the place to win benchmarks. Rather look for Global access , SQL optimizing, ....
Totally agree, way more important to produce readable easily supported code, especially by non-Caché folk.
I wasn't sure.
therfore: .... some kind of code optimizer eventually might run.
I remembered a discussion around Java JIT compiler and XEP being faster on globals that pure COS.
But I can't remember any result or consequences.
It's better to use more readable approach in these cases. It's somewhat doubtful that your app spends much time on local sets.
Use ^PERFMON to track performance issues. Also @Murray Oldfield wrote a series of articles on performance, check it out.
https://community.intersystems.com/post/apm-finding-expensive-parts-your...
also describes how to locate expensive points in your code.
In this case you are talking about tiny differences. If this is executed millions of times in a common path that is executed frequently you might want to think about it, but for most applications it is not an issue. Those SQL queries that don't use an index are the killers.
I also want to note that
s (a,b,c)=0
is slower than
s a=0,b=0,c=0
To answer your question via timed tests:
Query 1 (Iterating 100 million times...) :
Example 1 :
64708,68916.71
64708,68926.342
Example 2:
64708,68900.72
64708,68910.376
Query 2 (Iterating 1 billion times!!!):
Example 1:
64708,69223.394
64708,69246.773
Example 2:
64708,69264.946
64708,69289.174
@ Vitaliy Serdtsev (100 million iterations)
64708,69571.214
64708,69577.797
64708,69589.118
64708,69595.433
64708,69793.562
64708,69799.545
As everyone said, setting variables/ conditional statements is probably not where it's getting slow. As someone mentioned PERFMON is a great tool . Another one is ^%SYS.MONLBL.
I just got too much bloody time ....