On Sun, Aug 12, 2007 at 10:34:16AM +0200, Tilman Sauerbeck wrote:
Anton Vorontsov [2007-08-12 02:35]:
On Sat, Aug 11, 2007 at 05:10:12PM +0200, Tilman Sauerbeck wrote:
Tilman Sauerbeck [2007-08-09 01:16]:
over the last few days I have started working on the next major incarnation of pkgutils, version 6.
I was bored earlier today and compared the run times and memory usage of "pkginfo -i" from pkgutils-c 1.5 and the tip of the pkgutils6 branch.
I only ran each binary once, as I'm mostly interested in memory usage here (memory usage should be constant no matter whether you're running with a hot or a cold cache, whereas run time typically won't be).
Here's the graphs from valgrind resp. massif:
pkgutils-c 1.5: http://crux.nu/~tilman/pkginfo_i.1.5.png pkgutils6: http://crux.nu/~tilman/pkginfo_i.6.png
I'll leave the interpretation of these graphs to you ;)
I really doubt that you didn't know the reason:
Yes, I do know the reason. Hint: don't start your replies by implying ignorance. It doesn't really increase my willingness to give a thorough answer.
I.e. you're just reading package names in memory. So, you're using ad-hoc methods, and yes they're faster, eat less memory. While pkgutils-c's functions to the database done w/o premature optimizations:
I remember that you accused me of wasting memory. Guess in the pkginfo-i case it's you instead who's eating RAM alive.
You're speaking about completely different things, and you _know_ it. Doing struct pkg { char name[NAMESIZE]; char version[VERSIONSIZE]; ... }; Is just ugly and regression against _original_ pkgutils, you're adding constraints, and wasting memory w/o any hope to easily optimize it. And I told you about _that_. You seem to "fix" it after: struct pkg { ... char version[VERSIONSIZE]; char name[]; }; Heh. You've "fixed" name, but in the current code you can't easily fix version's constraint (or any another), and well... you didn't. On the other hand, not-reading files listing on -i - is a light and easy to do optimization, not some memory management issue that you've made ugly from the very start. And I hardly can imagine where you've found similar points of these two issues, and why you've decided to use silly "-i" example to show that pkgutils-c "ZOMG wastes" memory. Unrelated to this email: please, remove all those constraints, implement all the features, test, fix bugs and then compare. Will be pkgutils6 faster? With less memory consumption? Okay, I'll have reference point to optimize my code. Until that, _you_ have two reference points - pkgutils-c and C++ish pkgutils, while I have none for today. And I know it's easier to have it than not (I was using C++ish pkgutils for it). Good luck, -- Anton Vorontsov email: cbou@mail.ru backup email: ya-cbou@yandex.ru irc://irc.freenode.net/bd2