Arun Kumar · Feb 1, 2018

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. 


Arun Kumar Durairaj. 

0 874
Discussion (11)5
Log in or sign up to continue

query 1 misses a variant:

set $lb(a,b,c,d,e,f)=$lb("345","arun","kumar","hi","yello","orange")

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. 

...Example1 is faster by less line terminations

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.



  j=1,2/*,3,4,5*/ {
    j,") "

    d @("j"_j)(N)
    w $zh-time," s.",!
j1(N) public {
j2(N) public {
j3(N) public {
j4(N) public {
  i=1:1:{a=0 b=1 c=2 d=3 e=4 f=5}
j5(N) public {
  i=1:1:{s $lb(a,b,c,d,e,f)=$lb(0,1,2,3,4,5)}


1) 11.814189 s.
2) 4.683832 s.

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.

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
is slower than

To answer your question via timed tests:

Query 1 (Iterating 100 million times...) :

Example 1 :

w $ZTS F i=1:1:100000000 {S a="345",b="arun",c="kumar",d="hi",e="yello",f="orange"} w !,$ZTS                                                              
~9.632 secs

Example 2

w $ZTS F i=1:1:100000000 {S a="345" s b="arun" s c="kumar" s d="hi" s e="yello" s f="orange"} w !,$ZTS                                                    
~ 9.656 secs

Query 2 (Iterating 1 billion times!!!): 

Example 1:

w $ZTS F i=1:1:1000000000 {S:a=1 R="Arun"} w !,$ZTS                       
~ 23.379 secs

Example 2:

w $ZTS F i=1:1:1000000000 {I a=2 S R="Arun"} w !,$ZTS
~ 24.228 secs 

@  Vitaliy Serdtsev (100 million iterations)

w $ZTS F i=1:1:100000000 {s (a,b,c)=0} w !,$ZTS
~6.583 secs
w !,$ZTS F i=1:1:100000000 {s a=0,b=0,c=0} w !,$ZTS
~6.315 secs
w !,$ZTS F i=1:1:100000000 {s a=0 s b=0 s c=0} w !,$ZTS
~ 5.983

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 ....