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

[bruno.desthuilliers at gmail.com]

On 6 avr, 15:41, tinn... at 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("configFile", '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