Slow startup?

Jo Vermeulen jo at lumumba.luc.ac.be
Thu Apr 14 18:53:49 BST 2005


Op 14-apr-05 om 18:50 heeft Jo Vermeulen het volgende geschreven:

>
> Op 14-apr-05 om 16:12 heeft Fredrik Lundh het volgende geschreven:
>
>> Jo Vermeulen wrote:
>>
>>> powerhorse:~ jo$ python -c "import platform; print 
>>> platform.platform()"
>>> Darwin-7.8.0-Power_Macintosh-powerpc-32bit
>>>
>>>> (iirc, some Mac OS X builds/configs are extremely slow on some 
>>>> operations)
>>>
>>> Oh, I didn't know that.
>>
>> if you have some time to spare, and feel curious enough, you could 
>> try running
>> bzr under a Python 2.4.1 built by pythoneers:
>>
>> http://bob.pythonmac.org/archives/2005/03/31/macpython-241-installer/
>
> Still the same problem:

Hmm, the bzr script contains this:

if __name__ == '__main__':
     sys.exit(bzrlib.commands.main(sys.argv))

If I change it to:

if __name__ == '__main__':
     print "Hello, here we are already!"
     sys.exit(bzrlib.commands.main(sys.argv))

the message gets printed almost instantly. So I guess the sys.exit call 
is slowing things down (duh) :-) The main routine in commands.py seems 
to be the cause.

I added some print information. And I think I found the cause:

$ bzr
Creating trace file...
Done
Running bazaar...
usage: bzr COMMAND
   try "bzr help"
Done

It takes very long to create the trace file in the main method of 
commands.py:

bzrlib.trace.create_tracefile(argv)

So I added some more print statements:

powerhorse:~/Desktop/bzr.dev/bzrlib jo$ bzr
Creating trace file...
Let's start with this tracefile!
Created file
Written contents
Importing atexit
Registering _close_trace
Done!
Done
Running bazaar...
usage: bzr COMMAND
   try "bzr help"
Done

Now it takes very long to get to "Written contents", which then 
proceeds on the fly.

After examining some more, a lot of time was spent on this line:

t.write('  by %s on %s\n' % (bzrlib.osutils.username(), 
socket.getfqdn()))

bzrlib.osutils.username() calls auto_user_id() which takes the most 
time. And the slowest part of this method is a socket.getfqdn call at 
the end, just as the second parameter to t.write is.

Eliminating these calls (socket.getfqdn), but still including all the 
extra printing I did cuts off 2 whole seconds!

$ bzr
real    0m0.557s
user    0m0.310s
sys     0m0.120s

So it is wise to limit the use of socket.getfqdn or maybe try to 
preprocess it (make it a member?). Hopefully this information is 
useful.

Kind regards,

-- 
Jo Vermeulen <jo at lumumba.luc.ac.be>
http://lumumba.luc.ac.be/jo/





More information about the bazaar mailing list