Python init (was: bash vs. python scripts - which one is better?)
David Brodbeck wrote:
The other is that the load time for bash is shorter. Everyone complains
that their system boots too slowly as it is. ;)
Microscopically. On the other hand it has been my experience that it
isn't the load time of bash that is the problem, it is the constant fork/exec
to other applications to perform the work that is the problem. I haven't done
it recently with Python but back when I was coding Perl professionally often
the best optimization step I could make for shell was to rewrite into Perl
just to cut out the thousands upon thousands of forks/exec that the shell
scripts would perform to do simple tasks.
When it comes to Python in a role of system initialization there are some
very simple things one can do that would dramatically increase load times.
First off the pre-compiling of modules that Python does means subsequent boots
would not have to go through that step. One could ship the distribution with
those modules pre-compiled and only edits from that point out would be
compiled on their first run.
Also the entire init structure only requires one load of Python and not
dozens ala Bash. I often employ this simple technique when I want to build a
script with discrete modules which I want to have run by simply having their
presence in the directory:
mods = os.listdir(moddir)
for mod in mods:
pathname = os.path.splitext(os.path.absdir(os.path.join(moddir, mod)))[0]
inmod = __import__(pathname)
inmod.main()
That is a simplistic, non-ordered method of importing and running modules
by just having them in the directory. The only requirement is that the module
have a callable method called main(). By putting some simple sort logic in
front of the for loop one can quickly and easily replicate the init logic as
it is now and never once step out of a single instance of Python.
There are also maintenance issues with incorporating a complex language
that's under active development as a critical part of an operating
system. FreeBSD dropped Perl from their base system because "base Perl"
became such a pain to maintain. They were essentially put in the
position of having to fork Perl to maintain any sort of stable target,
and that was more work than they wanted to take on.
But.. I thought nothing was ever dropped from Perl. >.>
In all seriousness I can see that that could be an issue. I don't see it
as insurmountable. Maybe the right method or mindset is not yet there?
Reply to: