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

Thursday, November 17, 2005

Some statistics

Yesterday was somewhat less active coding day, still focused on bugfixing the BT module. I still have some issues open related to cross-file hashing, which is the reason why I'm not making new builds just yet. Still, a number of bugs were fixed yesterday, for example we now correctly handle torrents exceeding 4gb size, also I finally figured out why some clients were sending chunks of length 0 always - apparently I had forgotten to take the remote client's chunk-map into account when selecting chunks to download. Furthermore, as I had split the request-generation code (rather resource-intensive currently) into 4 separate functions the day before, yesterday I was able to eliminate one of them completely - getLeastUsed(), and incorporate the logic in there into getNextPartial(). getLeastAvailable() already takes use-count into account, so we won some cycles there.

A few days ago (on 15th), Hydranode became 18 months old, which was also the original estimated development time for the project, I figured this is appropriate time to do some statistics on the codebase, to see the amount of code produced during this time, development speed and so on. So here's the details.
Total lines of code:      53223
Lines of executable code: 35783
Lines of comments/docs: 17450 (32%)
Executable code per component:
- hnbase library: 7673
- hncore library: 7437
- edonkey module: 8292 (excluding the crypto code)
- hnshell module: 1913
- bittorrent module: 3319 (alpha status)
- http module: 2036 (beta status)
- core/gui comm module: 1011 (pre-alpha status)
- ed2k/kademlia module: 782 (pre-alpha status)
- directconnect module: 683 (pre-alpha status)
- email notif. module: 122 (beta status)
- ftp module: 281 (pre-alpha status)
Average +code/month: 2901 ( 1987 when excluding documentation)
Average +code/year: 34812 (23844 when excluding documentation)
Development time: 18 months
- 1 fulltime dev
- 1 parttime dev
- 3-4 random contributors
- 5-10 active testers
Average ~50 checkins/week in SVN repository (tops at ~70)

To give you a comparison value, aMule v2.0.3 is 93547 lines total, out of which 22847 lines (24%) are comments/documentation. eMule 0.46b is 142039 lines total, out of which 20820 (14%) lines are comments/documentation. eMule is roughly 46 months old (started early 2002), which means 3087 lines/month, 37044 lines/year development rate. aMule is based on eMule codebase, so time-wise calculation can't be done there.

What does all this show? First, we see that when we include documentation in coding-speed calculation, Hydranode is near eMule, and considering Hydranode has 32% documentation compared to eMule's 14%, we see that writing documentation is a considerable hit for development speed. We can also see that since the creation of LMule (the first eMule linux port, on which aMule is based upon), eMule has evolved faster than aMule, but aMule has become more documented, so we can deduct that aMule developers value documentation, and thus code quality over more features.

But, we'r getting off-topic here, we were looking at Hydranode's statistics. We can see that about one-third of the current codebase is in base and core libraries, which is good - large amount of code is shared between modules. eDonkey module, being the oldest and most feature-rich is naturally the biggest module, even passing core library in size. Bittorrent module, however is catching up fast, altough I estimate BT module will cap at around 5000 lines of code, since the protocol is lot simpler (and DHT implementations, both Mainline and Azureus ones, will go to separate modules). Http module, despite sounding really simple and straight-forward when you think of it, is still a considerable amount of code, due to a number of features, such as proxy, usernames/passwords, etc support.

In general, it would seem that we are roughly up-to-par, perhaps only slightly behind, with development speed compared to other projects. I'm aware of the fact that eMule actually has three active developers (maybe more that I'm not aware of), aMule has 3-4 I think, and this is not counting external contributions, but I don't think breaking the statistics up for per-developer is worth it. Also, neither eMule nor aMule have the strict 80-chars-per-line limit as Hydranode has, which affects the statistics - if Hydranode was written in eMule-style (I'v seen 200-character lines in emule code), the total lines of code would be less, thus indicating even slower development speed. Some might argue that Hydranode is much more complex application, but that's not true - complexity is relative and cannot be measured. What may be complex to one developer may be easy for other developer, and vice versa. Just as we have really complex issues with, say, BT virtual file wrappers, eMule devs have really complex issues with some wierd MFC control not doing what they want it to do - solving complexity always takes time.

All in all, while it seems really odd that a project has gone on for 18 months, and is still in it's 0.1 release series, from raw statistics it becomes apparent that we'r actually quite on-track with development speeds, compared to other clients. The illusion that Hydranode is still very young project comes from the fact that other projects have become widely usable a lot sooner, for example eMule got it's 1'000'000th download just after 4 months since the project was registred on SourceForge. This can be explained by the fact that the other clients have user interfaces built-in (or engines built into user interfaces :)), which means they became usable to wider audience lot earlier in the development process. However, with Hydranode, we have one fully-featured network module, and are developing second large network plugin, yet have no user interface to speak of, the latter of which creates the illusion.


Well... even lacking an interface, Hydranode surely is the best client out there. After I got my hands on the first usable build, I never let go. And I'm sure it will only get better and better. Can't wait to start using the Torrent module! Ah, the dream of multi-net downloads! :)
Great work, Madcat & co.
It is good, but until it offers the same performance as other clients, I cannot justify using it. Especially for rare files, Kad is vital, as is (to a lesser extent) distributed tracking for BT.

I also believe that once a basic (but usable) GUI is implemented many more people will notice the project and hence offer help with coding and tracking down bugs. Then people will be able to offer non-critical code such as first-start wizards that help the user configure their firewalls and speed limits, and automatic updating (a must in my opinion, I am many times more likely to update my software if doing so only requires pressing OK in a dialog [ĀµTorrent does this beautifully, Azureus manages this OK, but takes a lot longer due to its size and because it downloads the updates by torrent, eMule only launches your browser, not good enough :D])
Already 18month? and not cake? :)

well i'm very impressed by all ur work in all this time! all i can say is that i hope to start writing as good and fast as u :)

I for one welcome our WithoutGUI P2P overlord! :P

( ok too much /. i know... :P )

anyway my best wish for the project i can't wait to see when you will first start publish it to the "dumb" users!
Post a Comment

<< Home

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