kiwi-ltsp

24 02 2008

I’ve been involved a little bit in a project called KIWI-LTSP. Basically, the aim of the project is to make it as easy as possible for openSUSE users to install/configure LTSP. Jigish, Cyberorg, Gohil, the man behind the project, informed us on IRC that it just won a FOSS India Award.

Rock on cyberorg!





Things that “never” happen…

28 01 2008

Just had to report what happen in #opensuse-gnome today;

<kallepersson> Just a bit of thankfulness this monday morning: The search field in the SLAB menu is so damn awesome! 🙂
<captain_magnus> Hmm… What’s wrong with this picture… People don’t say thank you when something is working… 🙂
<kallepersson> Hah.
<kallepersson> Just thankful I guess.
<captain_magnus> 🙂
<kallepersson> If it wasn’t for SUSE I guess I’d still be stuck on that horrible *other operating system*
<kallepersson> Ew.
<captain_magnus> OS/X you mean? Hehe…
<kallepersson> Um. Not really, no 🙂
* captain_magnus saved kallepersson’s quotes for future use…
<kallepersson> Feel free to 🙂
<kallepersson> I run my own business, and that’s where I run SUSE – if it is of any importance.
<captain_magnus> What do you do?
<kallepersson> I run a small web agency.
<kallepersson> I needed a fast operating system that “just worked” and was virus-free.





Fun with Beyonwiz

23 01 2008

A while ago, I bought myself a Beyonwiz DP-S1. I bought it as it had network connectivity so I thought it would be possible to have all sorts of fun with it. But to my disappointment, it wasn’t possible to connect to it, other than via http (which, as far as I know, can only be used to download recordings).

But the other day I found that someone created a patch to enable telnet access to it. But to apply the patch, you were required to have windows and an older firmware. Luckily, some tools were released as well so I could use my beloved Linux box to enable telnet access myself.

Once I had access to the box I started to explore it. To be honest, it doesn’t contain a lot of fun toys that are usable. But there was one utility… It’s called micomparam. It seems to control a lot of functionality in the hardware, amongst one is the display at the front. While I was playing around with it I came up with this really geek idea. Why not use the display on the PVR to let me know when I have new emails in evolution. So I setup a quick bash script that that listens on DBus when new messages arrive. I then use expect to access the PVR via telnet and set the display to show me when I have new emails.

I came up with other silly ideas as well, such as having the display show me when someone talks to me on IRC etc. But I have not done any setup for it yet (probably wont do it either). I think what I need to do next is to figure out if it is at all possible to manipulate the box further. It’s using Linux and BusyBox so it might be possible to write/compile software for it. I don’t know how one would go about trying something like that but could be worth a try. Even if it fails, it’s always fun playing. Beyonwiz have not released it’s stuff as required by GPL yet but according to this post, they are working on it. Meanwhile, I have something to waste my time on.





2007-12-25

25 12 2007

So I kept profiling m-m today.

I found that g_get_language_names called g_getenv a lot, which in turn calls getenv. This account for ~5% of the startup time of m-m as seen below;

m-m-org-glib

Since I know that Michael Meeks came to this same conclusion in his blog about gnome-menus, I decided to run a quick test with gnome-menu-spec-test. The result is this;

g-m-org-glib

Having a look at g_get_language_names I found that it does have a cache for language names, but it didn’t seem to be used efficiently. Now, I don’t know if there is a reason to find out if the language has changed while a program is running, but for the life of me, I can’t think of one.

Here’s a small snippet of the code;


if (!cache)
{
cache = g_new0 (GLanguageNamesCache, 1);
g_static_private_set (&cache_private, cache, language_names_cache_free);
}
value = guess_category_value ("LC_MESSAGES");
if (!value)
value = "C";
if (!(cache->languages && strcmp (cache->languages, value) == 0))
{
gchar **languages;
gchar **alist, **a;

It checks to see if it cached the language and if it did, retrieve the cache. Then it goes to check the language variables (no matter if it had a cache or not). I made a simple code change to NOT check the variables if the cache exists. Since I’ve never looked at the glib2 code before, I don’t know if the patch is sane, so I’ve asked for a review. But the cache here is per application, so changing the environment variables and starting a new application will work.

Result of the code change is this for m-m;

m-m-new-glib

And this for gnome-menus;

g-m-new-glib





2007-12-23

23 12 2007

The openSUSE GNOME Team spent last week hunting bugs in the GNOME Main Menu. Since I was on site at a customer, I entirely missed the event :-/

So I thought I should try to make up for it, by profiling g-m-m today.

The first thing I found was this;

document_tile_private_setup

Adding Favorite Documents and Recently Used Documents to m-m accounts for >20% of it’s startup time. Out of that, 19% is spent in gnome_vfs_mime_get_default_application.

Looking at the code for it reveals (surprise surprise) that it’s used to figure out what default application to open the document with. It seemed unnecessary to call such an expensive function for each Document so I decided to move it out of there. That meant that for each application, document_tile_private_setup would now use a standard function (run a function which in turn opens nautilus) instead. That standard function will only be called if the user clicks on a Document, so I added the call to gnome_vfs_mime_get_default_application in there. This will not only save valuable startup time, but also a little bit of memory.

The next thing I looked at, and it is one of my favorite things to do in Slab, is the creation of a context menu for each Document. Again, the only time it would be used, is if the user right clicks on a Document. So I modified the code to only create the context menu if the user right-clicks on a document. Again, some savings in both startup time and memory.

Then the third thing, and which took most of the time today, was the fix up the following;

g-m-m-init

The create_rct_docs_section accounts for 45% of the initialization here. All up, tile_table_new, which is called by each function that adds an item to m-m, is using 57%.

After moving the code around a bit (sounds easy doesn’t it?), and also fixed a bug, I ended up with this;

g-m-m-opt1

Now, that looks alright for a days work. Although not all finished with this yet (need to fix a bug that I introduced :-), it was a good day overall.

I tried to publish the diff here but wordpress didn’t like it much. Download it from here instead.

UPDATE!
I just realized that it looks a bit funny when comparing the two charts above. To clarify, it does not mean that the startup time have been reduced by >50%. These are numbers from the current view that I was looking at. Some of the work is now done in other functions which is not visible in the last chart. Once done with this first round of optimizations, I’ll try to publish a better view which shows how much we’ve gained.





2007-12-16

16 12 2007

I’ve been putting experimental code in AB to use a sqlite database for application cache.

To start, I created three tables;

create table Category (name TEXT PRIMARY KEY, id INTEGER);
create table Desktop (name TEXT, genericname TEXT, comment TEXT, exec TEXT, path TEXT PRIMARY KEY, id INTEGER);
create table DesktopCategory (desktop INTEGER, category INTEGER);

I then populate Category with the different categories, Desktop with all the applications and then the relationship table between Desktop applications and Categories.

On a warm startup (ie. everything is in filesystem cache), it saves 20% of the startup time compared to using gnome-menus.

I need to play around with this a bit more, but if it proves to be a feasible solution, then it’d be a good idea to store even more data in the database.

The biggest problem with doing it this way instead of using realtime data is obviously if AB doesn’t get started for a while and new software is added or removed. We’d end up for bad data.

Here’s AB using gnome-menus

AB using gnome-menus

And here’s AB using sqlite

AB using sqlite





2007-12-13

13 12 2007

I’ve been playing with Application Browser from the tile-2 repo. It’s nothing like AB in the original code and it feels so much faster.

Unfortunately, the previous profiling were done on my old machine which is no longer with us. Although not very important, it’d still be interesting to see how the two versions compare, so I will get some numbers from both and put them up here.

I’ve been running the new AB through valgrind to get a handle on what this new code is doing. While checking the results in kcachegrind, I found this tab called “Call Graph”, so I clicked on it. And for a while, I thought I died and went to heaven 🙂

This fantastic graph popped up my screen

callgrind-output-tile-2

I have yet to figure out if it can give me time instead of percentage, but it will certainly make life easier either way!

Apparently, Mikael Meeks have some ideas on what to do with gnome-menus  (in which AB spends ~30% of it’s time), so looking forward to hear his ideas.