Re: recommendations for faster IFS and string handling sub-procs.

[Scott Klement <klemscot@xxxxxxxxxxxx>]

On Sun, 15 Jun 2003, Richard B Baird wrote:
>
> in the tutorial, you used a pointer field instead of the really big varying
> options(*varsize) field for the returned record.
>

I used varying fields on Friday night because that's what your application
seemed to call for?

> looking at the two examples, it almost looks to me that it's like six of
> one, half a dozen of another.  in the first case, you are only passing
> pointers and integers - very fast.

In both cases you're only passing pointers and integers.  When you pass
a variable by reference (as I was doing in my recommended prototype with
the varying string) all that's being passed is a pointer that that
variable.

> but once you have the return values, you are still dealing with a field
> that is sized as the maximum size you could recieve, with the trimming
> overhead that implies.

That's not true.    In both cases, you're passed back a "length".   In my
example from the IFS tutorial, the length is the return value of the
procedure...   in yours, the length is the first 2 bytes of the varying
string.   In either case, there's a length there that you can use to
say "ignore anything after this point.

The overhead in trimming is when you don't know the length, and you have
to scan through the contents of the variable until you find the last
non-blank character (that's what %trim does).   It's unnecessary when you
have a length variable that tells you...

The advantage to my original approach is that it sets no absolute limit
on the size of the data you're storing the string into.  The one with
the varying string imposes a 32k limit.

The advantage to the varying string approach is that it's easier to use
for the pointer-phobic world of RPG programmers, and since the length is
self-contained within the string, the string is probably ready-to-use when
the procedure exits.

> in the second, you are sending the entire size of the maximum field size,
> but once you get it back, it's as small as the record size itself.

I'm not sure what this is trying to say. :)

> but after thinking about it, since the first example returns the record
> length, it seems that it might be faster - once recieved, you could do
> this:
>
> D Record                 32765A   varying
> D Line                   32765A
>
> c               dow     1 = 1
> c               eval    reclen = readline(fd: %addr(line): %size(line))
> c               if      reclen < 1
> c               leave
> c               end
> c               eval    Record = %substr(line:1:reclen)
> -------> process record
> c               enddo
> and then you are working with a varing string, only the size of the actual
> record.


True, but now you've made it much slower, because you're copying the data
from one variable to another.   It's faster than your original example
that you posted, since it's only copying the data that it NEEDS, not the
entire 32k.   But it's slower than reading the data into the varying field
in the first place.


> even if I set the maxlen to 32765, i'm not passing that data back and
> forth, and I immediatly reduce the field to a managable size.
> what do you think?

But you are passing it back and forth...   your copying it from "line"
to "record".   It's the copying of the string from one area of memory to
another that takes the time.

As I said, this is better than your original example, since you're only
copying the data you NEED instead of the whole string.   But it's slower
than reading the data directly into the variable you want it in.

But, you COULD do that with "readline":

  c               eval    %len(record) = 32765
  c               eval    reclen = readline(fd: %addr(record)+2:
  c                          %len(record))
  c               if      reclen < 1
  c               leave
  c               end
  c               eval    %len(record) = reclen;

I haven't tested this code, I'm just making it up as part of the text of
this message -- but, in theory, you're only copying the data one time,
from the file itself to the variable.   then, you're just setting the
value of an integer when you set the length.

> > I'm always changing the way I do things, constantly trying different ways
> > and different ideas, hoping to improve myself.
>
> me too, although i rarely improve my techniques for processing speed, only
> for coding speed and readability.  I hate looking at programs I wrote as
> little as a year ago - i'm like... 'what the heck was I thinking?'

Hehe... I think we all do that.