From mboxrd@z Thu Jan 1 00:00:00 1970 Delivered-To: chneukirchen@gmail.com Received: by 10.25.37.80 with SMTP id l77csp102577lfl; Sun, 5 Oct 2014 14:31:25 -0700 (PDT) Return-Path: Received-SPF: pass (google.com: domain of rack-devel+bncBD75LW742ECRBK7RY2QQKGQESAVKPLQ@googlegroups.com designates 10.180.228.74 as permitted sender) client-ip=10.180.228.74 Authentication-Results: mr.google.com; spf=pass (google.com: domain of rack-devel+bncBD75LW742ECRBK7RY2QQKGQESAVKPLQ@googlegroups.com designates 10.180.228.74 as permitted sender) smtp.mail=rack-devel+bncBD75LW742ECRBK7RY2QQKGQESAVKPLQ@googlegroups.com; dkim=pass header.i=@googlegroups.com X-Received: from mr.google.com ([10.180.228.74]) by 10.180.228.74 with SMTP id sg10mr391559wic.4.1412544684573 (num_hops = 1); Sun, 05 Oct 2014 14:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :sender:list-subscribe:list-unsubscribe:content-type; bh=Scpo1+Z8WxL2IS/ybVKEc3AADknZz6PGHyFbCJ8zjdM=; b=Ms7CGoWAMttzcP1sY2hX5Kc4+GBBaFRnUJoHPTGY7ypM3xi+jnManURwmNcFn8Gnoj WBlD7oI0M9mRQpnTGC3j47J8JegFxOLbN7kJpWG54oPRlnMLEmeuULvKa/SuL9ZNfdzs 7TC30QTMQv2dacjmkiL3ph/Smi9ZFo2exWuDCYG7rfPhH3AqzQ7AapRhI6JBRsqyZJGs j7+HAja9qyFRkz69t48RMNT2G6cUUHzzP4zmbrsT1Imr73wXolLjKFo0uldtp6So+mL1 IcVKNZNEOQ3XhRD3cQ7ccNXETDxHXR9FjSqHIwBvZ3vOWy4dEb8+2OXQSe9lL39OiBR+ VSyA== X-Received: by 10.180.228.74 with SMTP id sg10mr41408wic.4.1412544684452; Sun, 05 Oct 2014 14:31:24 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.180.85.170 with SMTP id i10ls458573wiz.37.canary; Sun, 05 Oct 2014 14:31:23 -0700 (PDT) X-Received: by 10.180.104.229 with SMTP id gh5mr108389wib.6.1412544683536; Sun, 05 Oct 2014 14:31:23 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [2a00:1450:4010:c03::22a]) by gmr-mx.google.com with ESMTPS id rb5si1188280lbb.0.2014.10.05.14.31.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 Oct 2014 14:31:23 -0700 (PDT) Received-SPF: pass (google.com: domain of jftucker@gmail.com designates 2a00:1450:4010:c03::22a as permitted sender) client-ip=2a00:1450:4010:c03::22a; Received: by mail-la0-f42.google.com with SMTP id mk6so3438756lab.15 for ; Sun, 05 Oct 2014 14:31:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.134.101 with SMTP id pj5mr19553392lbb.47.1412544683415; Sun, 05 Oct 2014 14:31:23 -0700 (PDT) Received: by 10.152.27.38 with HTTP; Sun, 5 Oct 2014 14:31:23 -0700 (PDT) In-Reply-To: <20141003200836.GA4664@dcvr.yhbt.net> References: <20141003200836.GA4664@dcvr.yhbt.net> Date: Sun, 5 Oct 2014 14:31:23 -0700 Message-ID: Subject: Re: Less allocated objects on each request From: James Tucker To: rack-devel@googlegroups.com X-Original-Sender: jftucker@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jftucker@gmail.com designates 2a00:1450:4010:c03::22a as permitted sender) smtp.mail=jftucker@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: X-Google-Group-Id: 486215384060 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , Content-Type: multipart/alternative; boundary=047d7b3a904415a1980504b3b064 --047d7b3a904415a1980504b3b064 Content-Type: text/plain; charset=UTF-8 Yeah, I've refused a previous patch on related grounds - this should be a language implementation target. I'm glad to hear that reached patches. Previously, back in the 1.8 days, I benched the aforementioned patch and it was slower than allocating the strings. It turns out that a simple Rack app, when you bench, will happily free these objects and not suffer major problems under high load with the allocations. If I remember correctly the prior patch added constant and method lookup time due to adding hierarchy too. On Fri, Oct 3, 2014 at 1:08 PM, Eric Wong wrote: > Hi all, this is about a recent rack.git commit: > dc53a8c26dc55d21240233b3d83d36efdef6e924 > > I don't disagree with this commit at this time, but I hope much of > it will become unnecessary as older versions of Ruby get phased out. > > Since Ruby 2.1.0, constant string keys are deduplicated in hash > literals. Thus the following reuses the same "key" string in every > case: > > { "key" => val } > # ref: r44058 > > Ruby 2.2 (coming December 2014) will also deduplicate the "key" literal > allocation for lookups and assignment on regular hashes: > > regular_hash["key"] # opt_aref_with (in insns.def) > regular_hash["key"] = val # opt_aset_with > > This speeds up the Rack env hash, but unfortunately won't help with > Rack::Utils::HeaderHash :< > (ref: r44551 + a few subsequent bugfixes) > > We originally planned to support dedupe for all strings (not just > literals), but that caused performance regressions :< > > On a related note, Ruby 2.2 will also use power-of-two sized hash > tables, speeding up lookups/assignments a little > (~10-20%, CPU-dependent) for String keys [Feature #9425] > > This only applies to mainline Ruby, I am not up-to-date with > Rubinius/JRuby internals. > > Thanks for reading! > > -- > > --- > You received this message because you are subscribed to the Google Groups > "Rack Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rack-devel+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to rack-devel+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. --047d7b3a904415a1980504b3b064 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, I've refused a previous patch on related grounds= - this should be a language implementation target. I'm glad to hear th= at reached patches.

Previously, back in the 1.8 days, I = benched the aforementioned patch and it was slower than allocating the stri= ngs. It turns out that a simple Rack app, when you bench, will happily free= these objects and not suffer major problems under high load with the alloc= ations. If I remember correctly the prior patch added constant and method l= ookup time due to adding hierarchy too.

On Fri, Oct 3, 2014 at 1:08 PM, Eric Wong= <e@8= 0x24.org> wrote:
Hi all, = this is about a recent rack.git commit:
dc53a8c26dc55d21240233b3d83d36efdef6e924

I don't disagree with this commit at this time, but I hope much of
it will become unnecessary as older versions of Ruby get phased out.

Since Ruby 2.1.0, constant string keys are deduplicated in hash
literals.=C2=A0 Thus the following reuses the same "key" string i= n every
case:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 { "key" =3D> val }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 # ref: r44058

Ruby 2.2 (coming December 2014) will also deduplicate the "key" l= iteral
allocation for lookups and assignment on regular hashes:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 regular_hash["key"]=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0# opt_aref_with (in insns.def)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 regular_hash["key"] =3D val=C2=A0 =C2= =A0# opt_aset_with

This speeds up the Rack env hash, but unfortunately won't help with
Rack::Utils::HeaderHash :<
(ref: r44551 + a few subsequent bugfixes)

We originally planned to support dedupe for all strings (not just
literals), but that caused performance regressions :<

On a related note, Ruby 2.2 will also use power-of-two sized hash
tables, speeding up lookups/assignments a little
(~10-20%, CPU-dependent) for String keys [Feature #9425]

This only applies to mainline Ruby, I am not up-to-date with
Rubinius/JRuby internals.

Thanks for reading!

--

---
You received this message because you are subscribed to the Google Groups &= quot;Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to rack-d= evel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups &= quot;Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to rack-dev= el+unsubscribe@googlegroups.com.
For more options, visit http= s://groups.google.com/d/optout.
--047d7b3a904415a1980504b3b064--