February 8th, 2015
January 14th, 2015
|09:41 pm - Inotify_add_watch/inotify_rm_watch perofrmance depends on the path|
Why is /tmp so much slower? The filesystem is the same (ext4). My only guess is that it has so many events that inotify_rm_watch has to do a lot of work to clear them.
December 3rd, 2014
|01:14 pm - Один из участников нашего проекта написал письмо про мудаков. Поможет или нет не знаю, но repost|
Originally posted by unera at Открытое письмо президенту РФ об информационной политике
В современном мире так сложилось, что институт частной собственности временами выступает мотором для развития общества, а временами - тормозом.
Известные мировые мыслители, такие, как Ричард Столлман, еще несколько десятков лет назад сумели оценить ту угрозу, которую несет миру распространение законов частной собственности на продукты интеллектуальной деятельности.( Эти люди, оценив...Collapse )
December 3rd, 2013
|10:07 pm - Urgent and important vs. anything else|
Making people do what you want them to do is impossible. They seem to always do what *they* want to do.
Do we need syntax highlighting in the command line client? Probably. Do we need it now? Definitely not.
But do we need colors in the *test runner*? Yeah, in 2025, perhaps! But we do have it now. And there is nothing I can do about it. Except this little revenge.
October 21st, 2013
October 2nd, 2013
|11:34 am - Performance of stdarg.h|
Most discussions I was able to find online about functions with variable number of arguments in C and C++ focus on syntax and type safety. Perhaps it has to do with C++11 support of such functions. But how much are they actually slower?
I wrote a small test to find out:
kostja@olah ~/snippets % gcc -std=c99 -O3 stdarg.c; time ./a.out
./a.out 0.18s user 0.00s system 99% cpu 0.181 total
kostja@olah ~/snippets % vim stdarg.c
kostja@olah ~/snippets % gcc -std=c99 -O3 stdarg.c; time ./a.out
./a.out 0.31s user 0.00s system 98% cpu 0.320 total
64-bit ABI allows passing some function arguments in C via registers. Apparently this is not the case for functions with variable number of arguments. I don't know for sure how many registers can be used, but the speed difference between standard and variadic function call increases when increasing the number of arguments.
September 28th, 2013
|02:27 am - Launchpad bug tracker|
The issue tracker on our source code host, GitHub, has matured enough for the team to make a decision to move.
It's probably not the best idea to criticize a free home for an open source project, after all, Launchpad wasn't making any money from hosting us, but, truth be said, and perhaps lack of business model is the reason, it has fallen behind in features and usability.
Just for the record, the most important problems with bugs at Launchpad for us were:
- 7-digit bug ids. Tarantool is a small project and we perhaps will never go out of 4 digits, and you often need to have a quick and easy "handle" for a bug during conversation or in a email
- too many attributes of a bug. The milestone and series system was again designed for a large project, and only complicated matters for us
- bug states were quite nice, but then again we only used a few of them. At the same time there was no "legal" way to mark a bug as a duplicate - perhaps something related to the internal policies at Canonical.
- no way to cross-link a bug and a commit, unless (I guess) you're using Bazaar
- no bulk operations on bugs.
GitHub issues solve a lot of the above, plus, and this is actually the main reason, the issue tracker and the code both benefit from being close to each other.
|01:55 am - New algorithm for taking snapshot in Tarantool|
Just merged in a patch which I think gives Tarantool one more small but important edge over any other free in-memory database on the market.
The patch changes the algorithm of snapshotting (consistent online backup in Tarantool) from fork() + copy-on-write to use of delayed garbage collection. The overhead per tuple (Tarantool name for a record) is only 4 bytes, to store the added MVCC version. And, since delayed garbage collection is way more fine-grained compared to page-splits after a fork(), as it works on record level, not on page level, the extra memory "headroom", required for a snapshot, is now within 10% of all memory dedicated to an instance.
This feature goes into 1.5, which is, technically speaking, frozen :), but the patch has quite good locality and has been tested in production for a few months already, so I couldn't stand the temptation of making it available ASAP.
Speaking of our master, 1.6, it has already got online add/drop space/index, space and index names, and now is getting ready to switch to msgpack as the primary data format. But since we withstood from making incompatible changes for almost 3 years, there is still a lot of wants and wishes for 1.6. So the current best bet is to get 1.6 out of alpha by the end of the year.
|01:47 am - open_memstream()|
Have you heard about open_memstream()? This is a nice addition of POSIX 2008.
Good little step towards bringing down the number of different string classes in an average C/C++ program.
September 16th, 2013
|03:32 pm - Relevance of regression test failures on exotic platforms|
Back in my days at MySQL we had a lot of issues with test failures. We had lots of platforms, and would try to run and maintain our regression test suite on all of them. I remember spending days investigating issues on some obscure OS (Mac OS, mainly, Windows was taken care of) or hardware (little-endian, mainly) .
With Tarantool, we never got to do that. We do run buidls on lots of platforms, and someone always screams when they break, since we only run builds on platforms which are in actual use. And they do break, so it's a lot of hassle. But we haven't had time to maintain the regression tests on some of these platforms. Ugly? Yes. Yet we know which systems people use in production, and do take care of these. This set is much more narrow than the set of systems which people play with.
And also, we don't pay attention to test failures caused by, essentially, bad tests. If a test fails once in a while on a busy box, well, this is kind of bad, but tolerable. One day we'll rewrite the test.
It turns out that these tests failures have very little relevance to what people experience in production. In the course of these 3 years I've never seen a test failure on an exotic platform being relevant to any production bug we've had.
Perhaps this is all possible since Tarantool team is so much smaller than MySQL. But it spares us all from lots and lots of boring and unneeded work.