Alo Sarv
lead developer

Donate via
MoneyBookers

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
irc.hydranode.com/#hydranode

Saturday, January 29, 2005

Finalizing PartData, upgrading hasher

Contrary to last nights blog post, namely regarding UsedRange concept's dropping, I realized I still can't drop it out completely, since I can't really track UseCount on chunks w/o it, and alternative solutions to do so proved causing even more problems. So, UsedRange is here to stay, at least with our current knowledge base I see now way around it. Anyway, it's not very big syntactical burden.

I got the locking and writing system somewhat operation, albeit it's not tested at all yet - was about to go there, but then realized I needed to upgrade hasher code too.

Hasher code used it's internal threading code, and owned a separate thread of its own. However, since the recent addition of WorkThread API to the codebase, it should start using that one instead. So basically I just threw away the 800-line hasher.cpp and modified HashWork object somewhat to also perform the work in question. The result: new hasher.cpp is 139 lines of code, and technically capable of doing everything the old one was (again, untested code).

This seems to be the trend lately - during rewrites, things get lot more compact, robust and simpler. I just happened to compare my current local code tree (on which I'v been working for about a week or so already) to what I have in CVS, and to my surprise, realized that my local source tree is 3500 lines of code SMALLER than what's in CVS. That's 3500 lines of code simply thrown away - current codebase (excluding testsuite) is 26'000 sloc, while the one in CVS is 29'500+. So - as authorities have said - "If your code is becoming both simpler and smaller, you'r on the right track" - seems it's a good sign. From what I can see right now, I see at least 1000-2000-line more code that can be rewritten into much more compact, cleaner and faster form (MetaDb/MetaData, Object, and DynObj Subsystem come to mind).

Madcat, ZzZz



Comments: Post a Comment



<< Home

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