Alo Sarv
lead developer

Donate via

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary

Friday, February 17, 2006

Low-level optimizations

The performance optimization made early today morning (see previous post) was a major success; some testers claimed cpu usage drop from 62% down to 28% (P2/200Mhz), and I have been unable to detect any regressions whatsoever inherent from the optimization. Seems you can have the cake and eat it too :)

Gaining confidence from that success, I decided to introduce two more low-level optimizations. The first one is in Scheduler layer, and it tweaks the bandwidth distribution algorithm between sockets slightly, so that the average size of a low-level send()/recv() call is now up to ten times larger than it was before (from 150 bytes to 1500 bytes). This should reduce the TCP overhead considerably.

The second one was done at SocketWatcher, where we call select() every event loop. The trouble with select() is that it returns immediately as soon as ANY of the polled sockets receive an event; however this means with many sockets, we perform the expensive operation of adding all sockets to the list to be passed to select(), and then select() returns almost immediately, saying "socket #10 is readable", and we go over the entire thing again. Now I introduced a 50ms sleep cycle right BEFORE the select() call, thus forcing a delay into the main event loop. This has the effect of having select() return events on multiple sockets during one call, reducing overall CPU usage further.

I also discovered a memory leak in Boost.DateTime library, namely in ptime stream output operator. This caused the current GUI to leak roughly 4kb/s memory; this also causes the core to leak quite large quantities of memory when enabling trace masks (since the times are written to hydranode.log). Currently there's no available fix, since this is deep inside the Boost.DateTime library; however it's effect on release builds is minimal, since those perform very little logging.

Madcat, ZzZz

Are Boost libraries too buggy? Do they said those bugs and about being fixed in next version?
No piece of software is ever flawless; the more complex the software, the higher potential for bugs it has. Boost is very complex, but the complexity/bug ratio is very low, which is the reason why I've chosen to use it.

We'r currently investigating the cause for this leak with Boost people.

PS: Considering that this leak seems to only affect MSVC, it's a high probability that this is standard library bug, rather than Boost bug; if it were a Boost bug, it would also affect other ports / compilers.

What about MinGW compile under win32 platform, free of this mem-leak?
The SVN-Server is still down... :-(
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?