On Fri, Jul 19, 2013 at 7:11 AM, Jer Noble <jer.noble@apple.com> wrote: > This is an implementation choice. Right now, neutered buffers are very > rare, so JSC has optimized the non-neutering case. It sounds like > SpiderMonkey has chosen a different optimization strategy, trading an > upfront cost (tracking and checking allocation sites) for limiting the cost > of the pathological neutering case. > Neutering isn't pathological. It's the solution the Web platform has settled on for avoiding data copies when transferring data between threads (and potentially other kinds of ownership transfer). I expect its usage to increase as people write more code using Workers and demand higher performance for that code. I would prefer to not make neutering any more common, not only because JSC > is already heavily optimized for that case, but because neutering violates > a design principle of ArrayBuffers, that their length is immutable. > If you consider neutering undesirable, you should have tried to block its introduction. Did you provide feedback to Hixie about that? If you feel strongly about this, please write to public-html and whatwg (maybe public-script-coord) explaining your position and asking them not to add new usage of neutering. This is not a good forum to make that kind of architectural decision. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *
Received on Thursday, 18 July 2013 23:37:31 UTC