Presumably an import is no faster or slower than opening a file?

[tinnews@isbd.co.uk]

I'm trying to minimise the overheads of a small Python utility, I'm
not really too fussed about how fast it is but I would like to
minimise its loading effect on the system as it could be called lots
of times (and, no, I don't think there's an easy way of keeping it
running and using the same copy repeatedly).

It needs a configuration file of some sort which I want to keep
separate from the code, is there thus anything to choose between a
configuration file that I read after:-

f = open("configFil e", 'r')

.... and importing a configuration written as python dictionaries or
whatever:-

import myConfig

--
Chris Green

[bruno.desthuilliers@gmail.com]

Re: Presumably an import is no faster or slower than opening a file?

On 6 avr, 15:41, tinn...@isbd.co .uk wrote:

I'm trying to minimise the overheads of a small Python utility, I'm
not really too fussed about how fast it is but I would like to
minimise its loading effect on the system as it could be called lots
of times (and, no, I don't think there's an easy way of keeping it
running and using the same copy repeatedly).
>
It needs a configuration file of some sort which I want to keep
separate from the code, is there thus anything to choose between a
configuration file that I read after:-
>
f = open("configFil e", 'r')
>
... and importing a configuration written as python dictionaries or
whatever:-
>
import myConfig

In both cases, you'll have to open a file. In the first case, you'll
have to parse it each time the script is executed. In the second case,
the first import will take care of compiling the python source to byte-
code and save it in a myConfig.pyc file. As long as the myConfig.py
does not change, subsequent import will directly use the .pyc, so
you'll save on the parsing/compiling time. FWIW, you can even
"manually" compile the myConfig.py file, after each modification, and
only keep the myConfig.pyc in your python path, so you'll never get
the small overhead of the "search .py / search .pyc / compare
modification time / compile / save" cycle.

While we're at it, if you worry about the "overhead" of loading the
conf file, you'd better make sure that either you force the script
compilation and keep the .py out of the path, or at least keep the
script.py file as lightweight as possible (ie : "import somelib;
somelib.main()" , where all the real code is in somelib.py), since by
default, only imported modules get their bytecode saved to .pyc file.

Now I may be wrong but I seriously doubt it'll make a huge difference
anyway, and if so, you'd really preferer to have a long running
process to avoid the real overhead of launching a Python interpreter.

My 2 cents...

--
Chris Green

[tinnews@isbd.co.uk]

Re: Presumably an import is no faster or slower than opening a file?

bruno.desthuill iers@gmail.com <bruno.desthuil liers@gmail.com wrote:

On 6 avr, 15:41, tinn...@isbd.co .uk wrote:

I'm trying to minimise the overheads of a small Python utility, I'm
not really too fussed about how fast it is but I would like to
minimise its loading effect on the system as it could be called lots
of times (and, no, I don't think there's an easy way of keeping it
running and using the same copy repeatedly).

It needs a configuration file of some sort which I want to keep
separate from the code, is there thus anything to choose between a
configuration file that I read after:-

f = open("configFil e", 'r')

... and importing a configuration written as python dictionaries or
whatever:-

import myConfig

>
In both cases, you'll have to open a file. In the first case, you'll
have to parse it each time the script is executed. In the second case,
the first import will take care of compiling the python source to byte-
code and save it in a myConfig.pyc file. As long as the myConfig.py
does not change, subsequent import will directly use the .pyc, so
you'll save on the parsing/compiling time. FWIW, you can even
"manually" compile the myConfig.py file, after each modification, and
only keep the myConfig.pyc in your python path, so you'll never get
the small overhead of the "search .py / search .pyc / compare
modification time / compile / save" cycle.
>
While we're at it, if you worry about the "overhead" of loading the
conf file, you'd better make sure that either you force the script
compilation and keep the .py out of the path, or at least keep the
script.py file as lightweight as possible (ie : "import somelib;
somelib.main()" , where all the real code is in somelib.py), since by
default, only imported modules get their bytecode saved to .pyc file.
>
Now I may be wrong but I seriously doubt it'll make a huge difference
anyway, and if so, you'd really preferer to have a long running
process to avoid the real overhead of launching a Python interpreter.
>

Thanks for the comments, mostly about what I was thinking too but I
just wanted to check that I'm not missing anything really obvious.

--
Chris Green