In the last days I struggled with the Visual Studio 2005 editor becoming extremely slow. Simply moving the cursor to the end of a line with 120 characters by holding down the right arrow key could take up to 5 seconds. VS2008 running in a VM under Linux was much faster.
I finally found the solution in an old thread at microsoft.public.dotnet.languages.csharp:
devenv.exe /resetuserdata
Not sure, what kind of setting was causing this slowness, but resetting to the defaults helped.
In the past, when upgrading Debian VDR and VDR plug-in packages, it could happen, that one or more plug-ins were not updated (maybe because they haven’t been uploaded yet or haven’t migrated to testing). This could be problematic, because the new VDR might have a changed ABI (Application Binary Interface), causing any old plug-ins to be unloadable due to their ABI incompatibility. Such an ABI incompatibility could also happen, when the VDR package was built with any optional patches, but the plug-in wasn’t compiled against the patched VDR headers.
To avoid crashes with such incompatible plug-ins, the wrapper script that starts VDR checked at runtime, if a plug-in matches the “patchlevel” (a string identifier in a custom control field of the Debian package, listing the names of the applied optional patches) and if the plug-in was loadable at all. This check was pretty slow, because it relied on getting the pachtlevel information via dpkg, so we recently introduced some kind of caching, which made the VDR start up procedure even more complicated.
When this topic came up again recently with bug report #489914, I had the idea to replace the weak runtime compatibility test with install time dependency checks using Debians virtual package / “Provides” feature. It’s a pretty simple solution and I’m wondering, why I haven’t thought about this before.
This is how it works: The VDR-Package has a ”Provides: vdr-abi-1.6.0-debian” entry in it’s control file and the VDR plug-ins just have a dependency on ”vdr-abi-1.6.0-debian”. This way you can’t install a plug-in without having a compatible VDR installed and vice versa. Any changes in VDR’s ABI must be reflected in the virtual package name like ”vdr-abi-1.6.0-debian-1” when having added a patch to the Debian package or ”vdr-abi-1.6.1-debian” when a new upstream version introduces a new ABI.
Under the hood, there’s happening a little bit more. With the VDR header package vdr-dev, /usr/share/vdr-dev/abi-version will be installed, which contains the ABI version name used in the Provides-field. It also installs /usr/share/vdr-dev/dependencies.sh which plug-ins may use to create a ${vdr:Depends) substitution variable, that will hold the correct ABI version name. So everything a plug-in has to do, is to have a ”Depends: ${vdr:Depends)” in its control file and to to call dependencies.sh during the build process.
The ABI version name, that the VDR package will use, is specified in debian/abi-version and from there finds it’s way to the “Provides”-field in the control file via the ${vdr:Provides} substition variable. It’s the package maintainers responsibility to change the ABI version name with every ABI changes that might be introduced in a new package release. The C++ ABI compatibility is well documented by the KDE team in “Policies/Binary Compatibility Issues With C++”
As a small safety network, the VDR package will check at build-time, if any of the applied patches (debian/patches) has been modified, by keeping a list of MD5 sums of all patches in debian/.vdr-patches. If a patch changes, the build will break until the md5 sums are manually updated with debian/rules accept-patches. Before doing this, the package maintainer should check, if any of the changed patches may affect the ABI-version and in this case has to modify the ABI version name in debian/abi-version.
This mechanism also supports building VDR in different “patch flavours”. By setting the environment variable “PATCHVARIANT”, a different set of patches from debian/patches can be selected. e.g.;
PATCHVARIANT=multipatch dpkg-buildpackage -tc -uc -us -rfakeroot
This will use the patches listed in debian/patches/00list.multipatch and it will use debian/abi-version.multipatch and debian/.vdr-patches.multipatch. The ABI version of such a patch variant should differ from the “vanilla” ABI version and all other patch variants, e.g.; “vdr-abi-1.6.0-multipatch-2008-07-26”.
The patch variants included in the packages available at e-tobi.net are “multipatch” and “extensions”. The official Debian VDR package will only contain the “multipatch” variant (but only a vanilla VDR is available as binary packages in Debian!).
To build your own patch variant, you have to:
PATCHVARIANT=mypatchvariant debian/rules accept-patches PATCHVARIANT=mypatchvariant dpkg-buildpackage -tc -uc -us -rfakeroot Das DIV-A VDR-System gibt es schon eine ganze Weile, ist aber erst jetzt auf meinem Radar aufgetaucht, denn das ganze gibt es inzwischen auch für den EeePC. Nicht dass ich so einen mein Eigen nennen würde, aber ich finde die Idee ganz nett. Das ganze baut wohl auf den 1.4’er VDR-Paketen von e-tobi.net auf, die für Xandros adaptiert wurden, und kommt mit HG-Treibern daher. Wer seinen bereits vorhandenen EeePC mit VDR bestücken möchte, für den gibt es eine Installationsanleitung und auch im VDR-Portal gibt es auch einen Thread dazu.
Auch wenn mein neues Notebook mehr oder weniger “state-of-the-art” ist, lässt sich da doch noch einiges mehr rausholen.
Ein Mehr an Laufzeit ist z.B. durch “Undervolting” möglich. D.h. die Spannung des Prozessors wird bis auf das äußerste Minimum reduziert, womit Leistungsaufnahme und Temperatur sinken.
Gerade Penryn-Prozessoren, wie der T9300, erlauben deutlich geringere Spannungen als die Default-Einstellungen vorgeben.
Eine sehr gute Anleitung zum Undervolting findet sich hier:
Im Normalbetrieb bei 1h Vollast zeigte HWMonitor bei mir eine Temperatur von 78° an. Bei maximaler Geschwindigkeit (ca. 2.5 GHz / 12x) wurde der Prozessor hier mit 1.1375V versorgt. Diese Spannung konnte ich um sagenhafte 0.175 V auf 0.9625 Volt reduzieren. Erst bei 0.95V kam es zu Abstürzen. Bei Vollast mit 0.9625V steigt die Temperatur gerade mal noch auf ein Maximum von 65°. Ein Temperaturunterschied von 13° ist schon recht beachtlich! Ob die angezeigten Temperaturen wirklich stimmen, kann ich nicht sagen. Andere Tools zeigen andere Temperaturen an. Die Differenz ist jedoch immer messbar.
Es lohnt sich, bei einem neuen Notebook das ganze mit dem vorinstallierten Windows zu testen, denn unter Linux wird das schon etwas schwieriger. Hier ist wohl zumindest ein Kernel-Patch notwendig. Aber wenn meine 320’er Platte endlich da ist, kann ich auch das testen.
Hanno Zulla now provides an Ubuntu repository with VDR packages. The packages are the same as the Debian-Packages on e-tobi.net, just rebuilt for Ubuntu. As far as possible, we try to keep the same source packages for Debian and Ubuntu, so that we can work together on both distributions. Right now the Debian packages are the “driving force”, meaning that bug fixes and updates are done on Debian/Alioth first and the Ubuntu packages then get updated.
Thanks Hanno!
