We have a symbolic field which calls a program.

Under ARev1 this works very well and fast. Under ARev 3 it is around 100 (yes 100) times slower making it unacceptable.

Any reasons for this?

We have also copied the data portion of a file from ARev1 to ARev3.

Under ARev1, printing a report takes about 1 second per 100 records.

Under ARev3, it takes 2-3 seconds per record. Ie 200 times slower.

Doing LIST FileX under ARev3 runs at normal speed.

The SELECT FileX under ARev3 is also normal speed.

Have tried DUMPLH and all the other DUMP/FIX utilities, but it has little effect on the speed.

Would appreciate any ideas.

Although my memory is not what it used to be .. I believe there was a BIG speed hit with Arev3 when it dealt with dictionaries tables etc which had '.' in them .. could this be the case since you have copied a Arev1 dataset over?

DSig

David Tod Sigafoos ~ SigSolutions

dsig@teleport.com

The file has some 10 dictionary items, only 1 or 2 with '.'.

The file has small records (approx. 50 bytes) but a large number of records (approx 30,000).

The program does a SELECT then LOOP:

  select fileX by ...

  loop

       readnext @id ..

  while ...

       read @record from File, @id ...

           print FMT(@record, 'R#8')

           .......

  repeat

The dictionary is not opened or used.

The select runs at normal speed.

Its the processing afterwards which is slow.

I suspect that subroutine calls are also very slow:

   call process.customer

Try using variables other than @id and @record (e.g. rec_id and rec).

Using @variables filters the reads through any MFSs attached to the file and may also cause a push/pop session.

Well, the program loader changed very little since 1.0. There is a check for dictionary records top ensure the object code is down at field 51 instead of 20 something like before. There is also an option that lets you enter in a location for uncataloged object code. The second only occurs on a failure on an exact read (the only dot/underscore conversion is on dictionaries, and that's actually in dict.mfs) and the second is just a quick if/then opcode, which would not account for hundreds of times slower.

I had run some tests before on plain code, no disk access, for timing between versions and found that the engine had not decreased in speed at all. There are other things decreasing speed, extra error checking, new functionality, status updates, some bad code updates, which cause some speed hits, but nothing in the engine itself.

What else is happening in the processing? I can see a few milliseconds on the FMT, with some new options and some portions being pulled from the ASM and meta's and dropped into basic, but nothing that would be 100 times as slow.

akaplan@sprezzatura.com

Sprezzatura, Inc.

Using @variables filters the reads through any MFSs attached to the file and may also cause a push/pop session.

Really? What makes you say that? I'm not familiar with anything in the code that would cause this result. The @vars are simply global descriptors accessable through all programs. Their use should not cause any sort of pushing or poping of sessions nor should they cause an increase in processing speed.

If I'm incorrect, I'd love to be enlightened.

akaplan@sprezzatura.com

Sprezzatura, Inc.

View this thread on the forum...