Archive for July, 2006

Some charts (II)

With the following chart I demonstrate the influence of the mail component in the last chart of yesterday. I took the same measure – switching components 50 times, but here only contacts, calendar, tasks and memos are involved. Note the difference of results, specially of contacts.

Yesterday (with mail): Mixed switching

Today (without mail): Mixed switching (4 components)

Moreover, time results are lower in the execution not influenced by the mail component.

And the following chart is a detail of the results of mail component published yesterday, where we can see the specific threshold of time increasing (around the 25th iteration).

Mail switching - detail

The next step… more sysprof!

Comments (2)

Some charts

I’ve tested more cases of components switching and here I post the charts which summarize the results.

* Mail: Ok, we see it yesterday, this strange increase of time when switching 50 times the mail component, but only from a threshold.

Mail switching

-> And what about the other components? Will they suffer the increase of time, too?

Let’s see…

Contacts: linear time… (except the first or second execution, this is common for the following components).
Contacts switching

Calendar:

Calendar switching

Tasks:

Tasks switching

Memos:

Memos switching

Mixed: We switch in the order Mail-Contacts-Calendar-Tasks-Memos. This is a bit special. Here, time increases again with a different multiplier factor for each component, although calendar, memos and tasks are similar.

*Edited* This is the right image, the one I removed hasn’t got data in correct order. Nevertheless, the conclusion is the same, because the disorder wasn’t important.

Mixed switching

Comments (2)

Timing tests

After take many profiles with sysprof, I wanted to measure time of switching.

* Syscall times() at the function e_shell_window_switch_to_component();
fprintf() of the component switched.

* Evolution starts up. Load of the last active component (contacts).
Time of switching: user 0,200000 seg, system: 0,020000 seg

* Switch of components once. Command: Ctrl + [1,2,3,4,5]
Component_id: mail;  Time of switching: user 0,400000 seg, system: 0,020000 seg
Component_id: contacts; Time of switching: user 0,120000 seg, system: 0,000000 seg
Component_id: calendar; Time of switching: user 0,320000 seg, system: 0,020000 seg
Component_id: tasks; Time of switching: user 0,070000 seg, system: 0,000000 seg
Component_id: memos; Time of switching: user 0,080000 seg, system: 0,000000 seg

* Switch many times from memos to mail.
It takes always the same time:
Component_id: mail
Time of switching: user 0,310000 seg, system: 0,000000 seg
We see that the time is less than the first time (due to the cache…).
But the component memos takes a little more time:
Component_id: memos
Time of switching: user 0,120000 seg, system: 0,000000 seg
-> Does it depends from which component we did the swtich?
Let’s take more timings.
What happens if I switch indiscriminately from task to mail? Ah! The times are different in every execution. For example:
Firstly:
Component_id: mail
Time of switching: user 0,340000 seg, system: 0,000000 seg

Component_id: tasks
Time of switching: user 0,150000 seg, system: 0,010000 seg

Component_id: mail
Time of switching: user 0,330000 seg, system: 0,000000 seg

Component_id: tasks
Time of switching: user 0,140000 seg, system: 0,000000 seg

Component_id: mail
Time of switching: user 0,350000 seg, system: 0,000000 seg

And later, when we do a lot of swiching, time increase (both mail and task):

Component_id: mail
Time of switching: user 0,450000 seg, system: 0,010000 seg

Component_id: tasks
Time of switching: user 0,180000 seg, system: 0,000000 seg

Component_id: mail
Time of switching: user 0,460000 seg, system: 0,000000 seg

Component_id: tasks
Time of switching: user 0,240000 seg, system: 0,010000 seg

Component_id: mail
Time of switching: user 0,550000 seg, system: 0,000000 seg

Component_id: tasks
Time of switching: user 0,250000 seg, system: 0,000000 seg

Then, I tested again mail-memo switch. No more identical times (like
the first test):

Component_id: mail
Time of switching: user 0,390000 seg, system: 0,000000 seg

Component_id: memos
Time of switching: user 0,160000 seg, system: 0,000000 seg

Component_id: mail
Time of switching: user 0,430000 seg, system: 0,000000 seg

Component_id: memos
Time of switching: user 0,240000 seg, system: 0,000000 seg

Component_id: mail
Time of switching: user 0,440000 seg, system: 0,010000 seg

Component_id: memos
Time of switching: user 0,250000 seg, system: 0,000000 seg

–> Any pattern?? Don’t know…

Let’s try other tests.

I put an extra button on the ESidebar. When it’s selected, it switches 100 times to the component mail.
It’s funny; the first and the second call takes:
Time of switching: user 0,420000 seg, system: 0,050000 seg
Time of switching: user 0,320000 seg, system: 0,000000 seg
And the last call #100:
Time of switching: user 1,340000 seg, system: 0,000000 seg
Note that the time increases for each new call. WHY?

More timing tests will be needed.
And I need a trace of this time increasing too!

Comments (7)

My jhbuild issues (el calvario llamado jhbuild)

Finally, I’ve finished all the installation of Evolution with jhbuild on my laptop (running a Debian unstable). I’ve found many obstacles during this process and I’d like to enumerate them here.

1. A lot of development packages were needed. Normally, I could guess which was the required package by the messages of jhbuild or the file config.log. For example, I haven’t installed a devel package of x11. Neither cairo nor pango complained about it, but gtk+ couldn’t compile and I didn’t know why. Well, this isn’t true. In fact, cairo complained about no X found, but silently… I discovered it in the config.log of cairo. Why coudn’t the configure of cairo find the X system? Well, checking the log I noticed that the header Intrinsic.h haven’t been imported… and it was from the libxt-dev package… apt-get install libxt-dev… OK!

2. The great problem, the dummiest and most difficult to detect was related to my shell paths. I wasn’t able to link some modules properly with the other already installed. Why? Because they intend to link with the libraries of my system. Echo $PATH, echo $PKG_CONFIG_PATH. Humm, suspicious – the first option in the path were my system libraries or binary locations. Any problem with .jhbuildrc? No, it was ok. And what about my .bashrc? There it was the stupid error. I’ve defined paths like ‘PATH_X=/path/1:/path/2:/etc’ instead of ‘PATH_X=$PATH_X:/path/1:/path/2:/etc’. When the jhbuild environment starts, it takes firstly the definition of variables from the .jhbuildrc file (which keeps the paths of the custom installation), and then from the .bashrc file (standard system environment). So, with the wrong way, it got the path of the system first and then the path of the jhbuild installation instead of jhbuild:system.

3. When I resolved the last error, I continued with more library problems. A library of my system was required (gobject), but the last last version (2.12). Not available at Debian unstable. Take it from Debian experimental :/ and go on.

4. With hal, I had problems with the version of libvolume-id too. The version required was older that the one available in Debian. Luckily, I found an RPM package of the old version and I installed it.

This is only a summary of my jhbuild issues, but gives an idea of my desperation these days… mostly because I had the sensation that I’d never finish the installation.

Finally, the building was completed. For execute evo from my own home I followed this Federico’s advice:

1. Create a ‘devel’ user.

2. xhost +

3. ssh -X devel@localhost

4. export DISPLAY=:0

5. jhbuild shell

6. execute evo

Without these steps I have problems 😦

Comments (1)

First post

Three years ago I used to write periodically a blog. It was funny but not necessary. So, my old blog lived only six months, as long as my enthusiasm existed. Today I inaugurate this (parallel private) blog because I’m participating in the Women Summer Outreach Program. Here I’ll post principally all the process of building my project (the optimisation of the components of Evolution).

Right now I’m building Evolution from jhbuild. It’s taking more time than I expected due to missing development packages in my Debian installation and other configuration problems. Besides, I’m going to start coding the LDTP automation scripts which I’ll need for next steps.

I expect I could start profiling soon, when all the Evolution package and dependencies have been installed. That will be the most interesting task!

Comments (3)