File Opens ARE a major killer -- even today -- we found that just building a
'named common' block used just in a SubRoutine called from dictionaries
helped SELECTs and SORTs and LISTs to perform MAGNITUDES better (We're
UniData, so YMMV)...

We test the 'FILEINFO' for the handle that is carried in NamedCommon, and if
FILEINFO for the named common was not filled in, we did the open.  Note that
you also need to store the 'current path' data as well in the NamedCommon,
and check that as well since the NamedCommon persists through 'LOGTOs' -- if
you have a LIVE and a TEST account, and you run in LIVE first, the named
common will still 'be there' if you simply LOGTO the TEST account - so
always test that the account/path used to open a file is the same on
're-use' of the file handle.

But I'm here to say - of all things, cache your file handles.

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Wols Lists
Sent: Thursday, August 05, 2010 10:23 AM
To: U2 Users List
Subject: Re: [U2] Universe 10.3 - Issues with I-Types when using subroutine
calls, and the dictionary items is Alt-key

 On 05/08/10 00:24, Aramaies wrote:
> Good Day,
>
>  
>
> We are in the process of upgrading from Universe 9.6 to 10.3, and we have
> noticed that the system performance is degraded when we use an I-Type
> dictionary with subroutine calls, and the item is also an alternate key.
>
> It seems that the report run about 4 or 5 times slower.
>
> Is there someone else who has encountered similar issues?
>
> Any ideas? 
>
What are you doing in your i-type? Optimisation of your code can make
quite a difference.

The more data that your i-type needs, that you can feed in via arguments
rather than (re)read from file, that's saving reads. If you need to open
files, cache them in named common because that USED to be a MAJOR
performance killer (much less so nowadays I believe, but still...)

Look at your code. The reference to an alternate key makes me suspect
you are suffering open/read penalties that you can hopefully optimise
away to a large extent.

Cheers,
Wol
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users


_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users

Reply via email to