Following up on Saturday's post and various other blog entries about bash.
While arguing with Anton about bash being slow, I discovered that /etc/bash_completion was sourced twice when starting a shell on my laptop; once in /etc/bash.bashrc, and once in ~/.bashrc. This is Debian bug #430501 - the suggestion there is that /etc/skel/.bashrc should change to check whether /etc/bash_completion had already been included. So, that saves 0.27 seconds.
tim@regulus:~$ time bash -i -c exit exit real 0m0.270s user 0m0.240s sys 0m0.032s
This is still ages when compared to zsh. A solution is proposed in Debian bug #467231 - the functions could be loaded dynamically when they are first used, instead of all at once. I may try this next.
One sandwich and cup of tea later: it works, and bash now beats zsh's time.
tim@regulus:~$ time bash -i -c exit exit real 0m0.047s user 0m0.036s sys 0m0.004s
Posted: 24 Mar 2008 00:00 |
So, a benchmark.
tim@regulus:~$ time zsh -i -c exit real 0m0.064s user 0m0.048s sys 0m0.008s
tim@regulus:~$ time bash -i -c exit exit real 0m0.540s user 0m0.436s sys 0m0.100s
Both shells had their respective completion systems enabled. (Without them turned on, bash actually beats zsh... but the times are small enough that it doesn't matter.) These times are with a warm disk cache - the first time through both shells were slower. And the numbers stay roughly the same when repeating.
Posted: 22 Mar 2008 00:00 |
Beginning last night, I reinstalled my laptop. Normally, if it were just to clean up some packages, I wouldn't do this - the aim was more to try out removing the disk encryption that I was using, and the effect has been quite dramatic.
I worked out a while ago that the device-mapper encryption was slowing down disk access - with it gone, boot times are much shorter (and I don't have to type in a LUKS passphrase). GNOME loads a lot faster. Additionally, bash starts a lot quicker than it did. I suspect loading the bash completion routines takes quite a bit of disk access. Update: No, I just didn't have the bash-completion package installed. Bash is still slow. GNOME is still faster, though... for now.
So, I will probably keep my new install. I need to investigate encrypting a USB device and integrating that nicely with GNOME and gpg.
Posted: 22 Mar 2008 00:00 |
Yesterday evening, I finally found the patch for a bug in mono-addins that had been affecting f-spot extensions for a while - rebuilding the f-spot Debian package with no changes and reinstalling would cause the built-in extensions to disappear. In the end, the patch was just two lines long, and had been applied in mono-addins SVN (and in the copy of mono-addins that f-spot bundles). One less RC bug for lenny.
With this out of the way, we uploaded f-spot 0.4.2-1 to unstable. This fixed another RC bug (two merged ones) and a handful of other problems. It's taken a few weeks since the upstream 0.4.2 release to get this pushed out, mainly because I knew upstream were expecting all the extensions bugs to be fixed in this release. Still, we got there in the end; there are still far too many known bugs in f-spot, but I think we will get a fair chunk sorted out before the release. In a couple of weeks, f-spot 0.4.3 should be upon us, and we have to decide whether it's stable enough to be uploaded to unstable. I need to forward some bugs and patches upstream before then. There's a known crash to fix in the next upload (but not too serious, relatively speaking) - but I rather want to let 0.4.2-1 migrate to testing, so perhaps we shall leave f-spot alone for a while.
So, over Easter, I have some time for some other projects.
Posted: 21 Mar 2008 00:00 |
This weekend, I visited Derby, and updated the f-spot packaging in the Debian pkg-cli-apps repository. It's now at version 0.4.2, but this hasn't fixed the complicated extensions problems - they are Mono.Addins bugs, so we'll need to update libmono-addins0.2-cil to the version the f-spot devs claim fixes everything.
Apart from that, I've been looking at my list of potential pet projects, and thinking about which of them I want to prioritize over the next year or so. I reckon I can organize them around the forthcoming Debian release - aiming to fix as many bugs as possible in time for lenny helps with rating the relative priority of things. It's probably not a coincidence that the more important bits of development I want to get done happen to tie in to Debian release goals. So I suppose now is not the time to start too many new projects. :)
The lenny release will also be a good time to step back and work out where I want to take things next. I volunteered to help with f-spot packaging because it was languishing with an obsolete version in Debian, and a slew of open bugs. It still has too many open bugs, but hopefully many can be be fixed before lenny. Still, after that, I suspect life is too short to be worrying about bundled Mono libraries.
Posted: 09 Mar 2008 00:00 |
FOSDEM was interesting, this year - I knew a lot more people than last time. Going to talks was a pain, because everywhere was so crowded; but the best bits are outside the talks, anyway.
I eventually managed to sign my keys from the keysigning, and even caught up with some left over from last year. The next day I fell horribly ill - I was recovering for the whole of last weekend.
I thought about Mono a bit. Miguel wasn't there this year, because last year he gave a talk or two about proprietary software that wouldn't even run on GNU/Linux. During a conversation, someone pointed out that Mono is designed to be binary-compatible with .NET executables compiled for Windows, and so its main aim is simply to run non-free software. Now, of course, there are some reasonable free apps written in C#; and there is an argument that GNOME needs rapid-development tools like Mono. But with the fun I've been having lately with f-spot, I'm not so sure that their community has the right idea about reuse of code and so on - they just keep bundling (and sometimes modifying) the source to libraries in their tarballs. Only this evening, I've found that f-spot have modified their copy of the FlickrNet library - it's not even grabbing a more recent upstream version, it's just their own code. Sure, rapid development - but at what cost?
So I'm not feeling keen on Mono at the moment. The trouble is, I don't really want to be associated with the trolls at boycottnovell, etc. I don't buy the conspiracy theories about submarine patents and so on - if you use Gtk# rather than the Windows.Forms implementation then it should all be fairly safe. Perhaps people troll because it's easier than coding?
Posted: 08 Mar 2008 00:00 |
| < | March 2008 | > | ||||
| Su | Mo | Tu | We | Th | Fr | Sa |
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | |||||
Tim Retout tim@retout.co.uk
JabberID: tim@retout.co.uk
I'm afraid I have turned off comments for this blog, because of all the spam. Let's face it, I didn't read them anyway. Feel free to email me.