I need time to read and think about all of Nick's comments so the following
is just to clarify the problem about many includes taking a long time on
vxWorks if NFX is not used..
> > Another goal was quick loading of ascii files. Thus the path mechanism is
> > not as general as that supported by the c preprocessor, i.e. the rules
> > always determine a unique place to locate an include file. The rules
> > work very well on Unix (less than 1 second to load all menus, record types,
> > devices, and drivers supplied with base). On vxWorks if NFS is used
performance
> > is still acceptable. If NFS is not used then there is about a 2 second
> > overhead for every file opened. This is not acceptable (> 2 minutes to
load).
> > This is the only reason for dbExpandAscii.
>
> Yes, but these times would be about the same if you had a search path
> mechanism since I believe all the files in base are actually in one
> directory which, (if you were sensible) would be the first in the path.
>
The problem can not be solved by an efficient search path.
The problem is that if NFS is not used vxWorks uses ftp.
Every time a file is opened vxWorks does the following:
1) Create ftp connection
2) Read entire file into memory
This happens EVERY time file is opened. The >= 2 second overhead
probable comes for establishing the ftp connection,
Marty
- Navigate by Date:
- Prev:
Re: Ascii databases Nick Rees
- Next:
Re: Ascii databases Nick Rees
- Index:
1994
1995
<1996>
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Ascii databases Nick Rees
- Next:
Re: Ascii databases Nick Rees
- Index:
1994
1995
<1996>
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|