Very Computer

by **Vance** » Sun, 25 Feb 2001 06:23:50

Recently a conversation came up at our shop pertaining to the use of

seem to believe that it no less efficient than OPENing a file. Others
believe it opens and closes the file each time....
If I use it, it's for sitautions like poping a code description on the
screen in a small program, or sometimes when maintaining a n already loose
program. Never from main routines. Things that concern me are... Does the
system whether it be UV/D3 whatever... Open this file and close it each and
every time, or when it opens it does it leave the file open until program
execution is halted. I honestly do not know the true answer... I have never
really looked into it deeply. It's notsomething I spread the use of, but do
use on occasion so it's never been a top priority to know the answer too...
I have written a few tests and in the long run they seem to come out
equivelent at run time.
I look at it this way if ACCESS can use it in an efficient way why would
basic doing anything else??? I would assume ACCESS leaves the translated
file open as well... (Uh oh another thing to think about)

This will probably start a whole coding ethics thread(which could be
interesting), or die(not interesting)...
I am interested in hearing the thoughts/facts on the use of it....

Vance Forste

by **BobJ** » Sun, 25 Feb 2001 18:19:41

I don't know the answer to the "open/close" thing, either, but how do you
handle the error situation if the translation fails because the item id is
not present or the file name is wrong? The few times that I've used the
translate in a program, I've set the variable to zero before the translation
then checked to see if it changed. Sounds like as much programming as
opening and then reading with an else clause. End users probably will never
see a difference, but it is an interesting thought.
BobJ

> Recently a conversation came up at our shop pertaining to the use of

us
> seem to believe that it no less efficient than OPENing a file. Others
> believe it opens and closes the file each time....
> If I use it, it's for sitautions like poping a code description on the
> screen in a small program, or sometimes when maintaining a n already loose
> program. Never from main routines. Things that concern me are... Does the
> system whether it be UV/D3 whatever... Open this file and close it each
and
> every time, or when it opens it does it leave the file open until program
> execution is halted. I honestly do not know the true answer... I have
never
> really looked into it deeply. It's notsomething I spread the use of, but
do
> use on occasion so it's never been a top priority to know the answer
too...
> I have written a few tests and in the long run they seem to come out
> equivelent at run time.
> I look at it this way if ACCESS can use it in an efficient way why would
> basic doing anything else??? I would assume ACCESS leaves the translated
> file open as well... (Uh oh another thing to think about)

> This will probably start a whole coding ethics thread(which could be
> interesting), or die(not interesting)...
> I am interested in hearing the thoughts/facts on the use of it....

> Vance Forste

by **Pete Jewel** » Sun, 25 Feb 2001 18:23:56

> Recently a conversation came up at our shop pertaining to the use of

> seem to believe that it no less efficient than OPENing a file. Others
> believe it opens and closes the file each time....

I've seen this method used exclusively in a subroutine for populating
screen fields, and was slower than opening the file(s) and accessing
the records directly.

I seem to remember reading that the OCONV translation method goes
through the motions of opening the file each time it is used, so is
therefore slow. Whether it closes the file afterwards or not, I can't
remember.

--
Pete

-------------------------------------------------------------
MaVerick - Open Source MultiValue Database Management System
Check out the website -> http://www.maverick-dbms.org

by **Ed Woo** » Mon, 26 Feb 2001 02:53:56

From my own experience, doing multiple tfile conversions run much slower than
simply opening the file and doing a read each time it was needed. Someone
correct me if i'm wrong, but the way it was explained to me a long time ago was
that each time you do a tfile conv, the file gets opened, the referenced item
gets read, attributes get counted until it reaches the desired one, that value
gets returned, the file gets closed, and the conv process wraps itself up.
Sounds like a lot of overhead for a simple read.

by **Doug Dumit** » Mon, 26 Feb 2001 04:58:28

On Fri, 23 Feb 2001 16:23:50 -0500, "Vance F"

>Recently a conversation came up at our shop pertaining to the use of

>seem to believe that it no less efficient than OPENing a file. Others
>believe it opens and closes the file each time....

... [snipped] ...

The use of translates in OCONVs and from ACCESS involves quite a bit
of "behind the scenes" work in terms of file opens and closes. It
also varies depending on the Pick "flavor". I will talk about "old
fashioned" Pick first (aka. R83).

If you OCONV from BASIC, the file is opened every call. The file is
not closed, but the base/modsep is overwritten almost immediately.
Remember that with R83, the concept of "closing a file" didn't really
exist. On the other hand, opening a file in R83 is basically reading
a couple of items, parsing base/modseps, and setting up a storage
register so the overhead is there, but is not really all that bad.

ACCESS cheats, but perhaps not in the way that you would expect. When
ACCESS gets the TCL command, it parses it into a run-time
specification which is what is actually executed. This run-time spec
includes attributes 7 and 8 of the dictionary items. Translates are
special cases that the ACCESS pre-processor converts from:

Tfile;x;;1

... to ...

Tbase.modsep;x;;1

With base and modsep stored in HEX. If you get really brave, you can
use the base.modsep syntax from BASIC, but it is possible to create a
lot of GFEs if you get the numbers wrong.

Moving on to AP/D3 (and I am guessing quite a bit here) you pick up
the concept of a file control block but I suspect that the process is
still pretty much the same.

With OSFI and mapped NT files, you then need to actually open an
operating system file. It is possible that D3 will "cache" these but
it might need to open/close them every translate. Again, I am unsure
of the internals here.

With U2 you are always in the host file system, so the file would need
to be either cached or open/closed each time.

-----------------------------------------------------------------
Easy Computing Company - Internet Hosting for mvDBMS Applications

Direct: 949 831-4774
Main Office: 888 473-7866
610 237-2000

by **CWNoa** » Mon, 26 Feb 2001 19:56:24

Vance,

Aside from being inefficient, TRANS is a lot less self-documenting than opening
a file at the top of a program. It indicates to me a lack of planning and care
on the part of the programmer (especially when it's added later). I've seen
TRANS used when the program already had the file open! Talk about slamming on a
fast patch and shoving it out the door...

Also, Jbase falls in the de* with no ability to continue if the file
happens not to exist. Right in the middle of that critical GL update, too. ;^)

Regards,
Charlie

>Subject: A little more BASIC coding banter

>Date: Fri, 23 Feb 2001 16:23:50 -0500

>Recently a conversation came up at our shop pertaining to the use of

>seem to believe that it no less efficient than OPENing a file. Others
>believe it opens and closes the file each time....
>If I use it, it's for sitautions like poping a code description on the
>screen in a small program, or sometimes when maintaining a n already loose
>program. Never from main routines. Things that concern me are... Does the
>system whether it be UV/D3 whatever... Open this file and close it each and
>every time, or when it opens it does it leave the file open until program
>execution is halted. I honestly do not know the true answer... I have never
>really looked into it deeply. It's notsomething I spread the use of, but do
>use on occasion so it's never been a top priority to know the answer too...
>I have written a few tests and in the long run they seem to come out
>equivelent at run time.
>I look at it this way if ACCESS can use it in an efficient way why would
>basic doing anything else??? I would assume ACCESS leaves the translated
>file open as well... (Uh oh another thing to think about)

>This will probably start a whole coding ethics thread(which could be
>interesting), or die(not interesting)...
>I am interested in hearing the thoughts/facts on the use of it....

>Vance Forste

by **Chester Johnso** » Mon, 26 Feb 2001 20:54:22

Quote:> From my own experience, doing multiple tfile conversions run much slower
than
> simply opening the file and doing a read each time it was needed. Someone
> correct me if i'm wrong, but the way it was explained to me a long time
ago was
> that each time you do a tfile conv, the file gets opened, the referenced
item
> gets read, attributes get counted until it reaches the desired one, that
value
> gets returned, the file gets closed, and the conv process wraps itself up.
> Sounds like a lot of overhead for a simple read.

This is how it was explained to me also. Because of the speed difference,
the only time I use the Tfile is when I need to only access ANY data in the
file 1 time during the program, usually at the beginning. When I find I
need to access a second piece of data in the file, I change things to open
the file. So far this has been a good rule. The reason I use the Tfile at
all is: since only 1 piece of data will be read from the file, there is no
reason to incur the overhead of an opened file while the rest of the program
executes (a hold over from when every command and every byte counted.)

Chester

by **Luke Webbe** » Mon, 26 Feb 2001 21:21:43

As usual, an excellent explanation from Doug. I just wanted to add one
little touch to let you see for yourself what he's talking about.

Find or write a dictionary attribute, then use it in an ACCESS sentence, but
use the (Y option. The ACCESS compiler will display the final form of all
dictionary items referenced, and where you had a file name, you'll now just
have a couple of numbers.

Luke

> On Fri, 23 Feb 2001 16:23:50 -0500, "Vance F"

> >Recently a conversation came up at our shop pertaining to the use of

us
> >seem to believe that it no less efficient than OPENing a file. Others
> >believe it opens and closes the file each time....

> ... [snipped] ...

> The use of translates in OCONVs and from ACCESS involves quite a bit
> of "behind the scenes" work in terms of file opens and closes. It
> also varies depending on the Pick "flavor". I will talk about "old
> fashioned" Pick first (aka. R83).

> If you OCONV from BASIC, the file is opened every call. The file is
> not closed, but the base/modsep is overwritten almost immediately.
> Remember that with R83, the concept of "closing a file" didn't really
> exist. On the other hand, opening a file in R83 is basically reading
> a couple of items, parsing base/modseps, and setting up a storage
> register so the overhead is there, but is not really all that bad.

> ACCESS cheats, but perhaps not in the way that you would expect. When
> ACCESS gets the TCL command, it parses it into a run-time
> specification which is what is actually executed. This run-time spec
> includes attributes 7 and 8 of the dictionary items. Translates are
> special cases that the ACCESS pre-processor converts from:

> Tfile;x;;1

> ... to ...

> Tbase.modsep;x;;1

> With base and modsep stored in HEX. If you get really brave, you can
> use the base.modsep syntax from BASIC, but it is possible to create a
> lot of GFEs if you get the numbers wrong.

> Moving on to AP/D3 (and I am guessing quite a bit here) you pick up
> the concept of a file control block but I suspect that the process is
> still pretty much the same.

> With OSFI and mapped NT files, you then need to actually open an
> operating system file. It is possible that D3 will "cache" these but
> it might need to open/close them every translate. Again, I am unsure
> of the internals here.

> With U2 you are always in the host file system, so the file would need
> to be either cached or open/closed each time.

> -----------------------------------------------------------------
> Easy Computing Company - Internet Hosting for mvDBMS Applications

> Direct: 949 831-4774
> Main Office: 888 473-7866
> 610 237-2000