2010/02/27

Re: Toke

Matthew gave me replies with some objections. I'm posting to my blog both because failed posting a comment to the original blog post and because it's a bit long, late and not so cool.
I do take objection to your comment in your blog post: “It’s a good example case that not expressing nor publishing in English leads products/opinions shall be ignored, and bad practice”. The simple fact is that I was not aware of yatce, and indeed, googling for “erlang tokyo cabinet” does not return any result for yatce until the 3rd page. If I had known about yatce in advance, then I would have tried to use it in preference to writing Toke: we have absolutely no desire to reinvent the wheel unnecessarily.
Yes, I meant 'ignore' as not being aware, just because I'm not so good at English. I'm sorry.

I don’t however understand your question about 16 tables. I’ve not come across limits on Erlang drivers and ports but maybe there’s something I’ve missed?
No, I had a memory of some limitation, seeing crypto module is using 16 drivers for more calculation speed. But again I search the erlang documents around and found no special statement about limitation of number of linkedin drivers.

If anything, it’s slightly slower than the current code (as well as being slightly more messy). It would seem the context switch is not hurting me at all. Even for tests which I would have thought would most expose control as being faster (eg lots of gets), it’s in fact no faster at all.
Yes, I was wrong. I thought too simply that context switching makes erts slower but context switching breaks some optimization (I don't know details and what it is) of Erlang runtime schedulers. They're using spinlocks...

After all totally you're right, matthew.
Post a Comment