Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Startup speed

The first implementation of getting mail messages from the Domino server was
straightforward: Open the server database and read out - one by one - every
single document. Then open the first given archive and loop over its documents
as well. Do so with every archive. When done, the startup phase is finished.

As I mentioned on the history page, I am still not having too much mail messages. Additionally I am
just using one singe archive on a local hard disk. The startup phase was not
really impressive, but still faster than Lotus Notes'. So I did not put too
much effort in optimizing that.

Then I recently got some reports about the slow startup speed of LNMail. So,
as with version 0.7 I tried to focus a bit harder on that. The first idea I
came up with, was the following: Since the Domino server stores the recently
received messages, there would be no chance to speedup that. But the archives
are stored on local hard drives or other network drives, which are independent
from the server connection. These messages could be read in parallel. So I
started to parallelize the startup process with quite good results: It seems
as if the speed improves with every used processor. When I was splitting my
messages into four separate archives, the startup time was divided by four.

So, for an optimal startup speed, I would recommend to use as many archives as
processors are available on the local machine. But this lead to another
thought: If the read process is limited by processor power, Lotus Notes
archives must be quite hard to decrypt, analyze or whatever must be done.
After parallelization, I needed around five to ten seconds for loading my mail
messages. But I only have under a thousand mails. Quit bad performance, I
would say.

This was, when I received an updated report from the above mentioned startup
speed. With the parallelization, LNMail started within fifteen minutes for
about 60000 mail messages. This would be unacceptable for me. 60000 messages
is not that much. An acceptable time would be around fifteen seconds, at
most! So, I had to come up with another idea. I tried to cache all the
important information I need. When selecting the appropriate preference, now
all message summaries are cached locally, when saving or leaving the
application. On startup, only the cache is read. After that, the application
can be used as usual, and a background synchronization takes place.

By using the caching option. The startup speed decreased to under a second.
Independently from any server or network connection. Now, I am awaiting new
reports ;-)