Jump to content


Photo
- - - - -

Calling global logic in batch update


7 replies to this topic

#1 Lewis Mccabe

Lewis Mccabe

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 455 posts
  • Gender:Male
  • Location:Sarasota, Florida

Posted 01 July 2005 - 09:06 PM

Hello All,

We are about to write a day end update for one of our applications. The structure will be greatly served if we could call a global update repeatedly from various different functions. How much of a performance hit are we going to take in doing global function calls instead of local? 6-7 years ago we did a full test on this very issue and determined we had to use local LS's (cycles). In 5.5 we have noticed there is a vast improvement in the performance of global functions. Anyone had a go at this yet?

Thanks.

Lew

Edited by Lewis Mccabe, 01 July 2005 - 09:07 PM.


#2 Bill Loven

Bill Loven

    Expert

  • Members
  • PipPipPipPip
  • 147 posts
  • Gender:Male
  • Location:Coppell, United States

Posted 01 July 2005 - 09:49 PM

:ermm: Lewis

I do this all of the time with now performance hits.

But our App Server is on Windows with 4 fast prossers and some really fast drives.

I prefer to write code one time and call it when I need it.

HTH

Bill

#3 Vol Yip

Vol Yip

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 393 posts
  • Gender:Male
  • Location:Hong Kong

Posted 02 July 2005 - 04:16 AM

HI,

I am having a similar problem.

In Superlayer, I have LU type function (though I do not flag it Global) and I have a Update function which will read a primary file and call this LU function in After Read No Error.

It takes an hour to finish if my primary file has 40 records and the LU function actually scan a big file with millions of records based on the primary file recored's parameters.

Do you think if I embedd the LU function into my U function (i.e., without being do a LSCALL) will help the performance?

Regards,

Vol

#4 Rob Donovan

Rob Donovan

    rob@proivrc.com

  • Admin
  • 1,640 posts
  • Gender:Male
  • Location:Spain

Posted 03 July 2005 - 12:30 AM

Hi,

It all depends on your application and if you need the 'raw' speed.

The performance hit is not much if you are just calling it a few times.. ie < 1000.

However, if you are calling it millions of times, it could be adding an overhead to your function.

You also have to consider if your application is used be lots of users. If you put in a Global LSCALL to a function that is used very frequently by your application (even if the Global Function is only calling 300 times each pass) and you have lots of users ( > 100) then this could also have an overall effect on your computers performance.

I have worked on a system with 100s of users and they all went through a central screen (function) and we had to be very carefull about Global LSCALLs in that function, as the wrong call could grind the system to a halt.

However, you have to balance performance with code saving....

Some places I have used duplicate LUs in functions, just because the performance was needed and critical.

I did suggest to ProIV LTD many years ago about 'caching' global function loads, I know they did try to do it but I dont think it worked. I have not checked recently if they have actually done this yet or not. When I get the time I will....

Rob D.

#5 Mike Nicholson

Mike Nicholson

    Expert

  • Members
  • PipPipPipPip
  • 196 posts
  • Gender:Male
  • Location:Stockholm, Sweden

Posted 03 July 2005 - 11:27 PM

I did suggest to ProIV LTD many years ago about 'caching' global function loads, I know they did try to do it but I dont think it worked. I have not checked recently if they have actually done this yet or not.

Last time they came round to talk to us it was on their 'to-do' list for version 6.

Take from that what you will..

Cheers

Mike

#6 CSuarezdelReal

CSuarezdelReal

    Advanced

  • Members
  • PipPipPip
  • 91 posts
  • Gender:Male

Posted 04 July 2005 - 10:05 PM

Vol Yip,

If you are not flaging your LU to be Global in SuperLayer, even though SuperLayer keeps a different code location for your LU, actually, when the host function is regenned, the resulting ProIV code WILL include LU as local (check your ProIV equivalent code to validate this).

I have found this feature to be very useful after understanding what the Global flag in LU (and Windows functions for that matter) does.

You can focus on performance ("Global" not marked), but need to regen every function that uses the LU if you change the LU itself; a function queue could do that nicely. Or you can focus on fast-coding ("Global" marked), but performance may suffer.

In SuperLayerI have seen a function running in 15 seconds instead of 45 minutes just unflaging "Global" when reading 50,000 records in 1,000 loops for the primary file. Another performace factor may be the way on which you look at those 50,000 records; an embedded SQL select use to make a huge difference even when selecting non-key fields.

Regards,
Claudio Suárez del Real
"It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change."

#7 Richard Bassett

Richard Bassett

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 696 posts
  • Location:Rural France

Posted 05 July 2005 - 10:00 AM

Lewis,

In 5.5 we have noticed there is a vast improvement in the performance of global functions.

That's _very_ interesting, are you able to give us a bit more detail?

We've also been moaning to ProIV about function caching for a long time but my understanding was the same as Mike's ie. I think they've done quite a bit of work towards it but I'm not aware anything has made it into a released kernel (yet).

[ProIV folks, if you're reading this and you know better, PLEASE enlighten us :)]

It's a big issue for us in addressing function workspace problems because, historically, trying to factor out the "inner loops" of a function into global functions (which is usually by far the easiest refactoring of course) has resulted in huge performance problems.
Nothing's as simple as you think

#8 Lewis Mccabe

Lewis Mccabe

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 455 posts
  • Gender:Male
  • Location:Sarasota, Florida

Posted 05 July 2005 - 04:10 PM

I see we hit a hot button here.

Rob,

Thanks. That is exactly the info we were looking for.

I prefer to write code one time and call it when I need it.

I agree with this without question - to the point that we are willing to sacrifice performance to a considerable degree to attain it.

Richard,

Here is more detail for you:

6-7 years ago we were unable to use global function calls in paging screens because of performance. That is not the case now (and we were using PRO-ISAM then and are using SQL Server now). I know P4 is not caching functions but it must have been tweaked enough to improve performance noticeably. What we do which works quite well, especially in paging screens, is to have a memory file which contains all the variables we need for the screen, but have them built from a global function. If the memory record does not exist, the global function is called which loads the memory variables. If it does, the variables we need are available by virtue of the memory file read. This reduces the number of times global functions are called, and once the variables are loaded, improves overall screen performance. The only issue you have is the first presentation of the paging data is not as fast as we would like (but not bad). After that, it is all driven from memory so it is lightening fast. Where this is applicable and appropriate, it works well.

We have converted all our old SL non global functions into VIP global functions. We are happy with performance but have not tested with more than 50 users.

Regarding cached functions: Last I heard, this was complete and implemented on the mainframe but nowhere else.



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users