4 ms·
Ok, its the former then. Slower than what? The great thing about HN, and similar discussion systems you'll find on the internet, is that you can read the conv
by buff-a 15y ago
Ok, its the former then.
Slower than what?
The great thing about HN, and similar discussion systems you'll find on the internet, is that you can read the conversation. So when I say "slower", and reference "antrix", a sentient (or even a reasonable AI) could infer that I was referring to this statement, by antrix:
>If I replace my memcache logic with an in-memory thread-safe hashmap, it will always be faster. I can't see how it can be slow.
And that you replied to by quoting it.
Clearly, by reading the english therein, antrix is comparing the memcache logic with a thread-safe hashmap. So in case you still aren't getting it, the answer to your question "Slower than what?" is "than a thread-safe hashmap". That you are not aware that this was antrix's assertion would explain why your subsequent posts fail to refute it.
So your behavior is not merely that of a response factory, but a response factory with a 1 deep context buffer.
- jbert 15y agoThe reason I asked "slower than what", is because at no point have I claimed that going to memcached would be faster than a local hash (with locking). Whereas I have (in this thread) claimed that an interpreter without a GIL (and with fine grained locking) would be slower than one with a GIL (for single-threaded workloads). I wanted to know which you meant. You haven't shown (I believe because it's not there) where I claimed that going to memcached would be faster. And you're being rude and trying to provoke a reaction. And HN is hiding the reply link because it's heuristics have determined that the signal/noise of these posts is likely to be low. And I agree and so won't reply further in this thread.