3rd-Eden/node-memcached — pull request #205 by ageitgey (2014-08-29 17:51:45+00:00)
Title: Workaround an issue in v8 that makes retrieving keys very slow for certain key sizes

We've run into a weird issue where retrieving large-ish json keys from memcached (~520kb) is incredibly slow and takes almost 2 seconds in certain cases. This issue is 100% reproducible in our application when retrieving certain key value sizes from memcached, but is very hard to produce in isolation in a stand-alone script where there isn't other memory usage going on. So admittedly this is a rare case that not many people would likely hit, but it's impact on us is pretty high and 100% consistent.

After debugging, we've tracked this down to a weird behavior in v8. This one line takes ~1600ms to run when the slow case is triggered:

```javascript
var chunks = S.responseBuffer.split(LINEBREAK);
````

If you replace that line with a messy `for` loop that does the same thing but never calls `split` or `indexOf`, the problem goes away.

It seems the cause of the slowness is related to [this v8 issue](https://code.google.com/p/v8/issues/detail?id=2869). When node-memcached builds up the new responseBuffer string, the BufferStream chunks aren't freed. If the value you are retrieving from memcached is fairly large, this can cause node to behave poorly, presumably trying to GC while doing the string split which makes it take almost 2 seconds.

This workaround (suggested in the v8 issue) forces v8 to re-allocate the buffer string first and thus free all the BufferStream chunks. With this change, this function goes from taking ~1600ms to just a few ms in our use cases and everything behaves as it should.