Received: by 10.236.79.164 with SMTP id i24mr13713602yhe.8.1338878541043;
        Mon, 04 Jun 2012 23:42:21 -0700 (PDT)
X-BeenThere: v8-users@googlegroups.com
Received: by 10.236.124.81 with SMTP id w57ls6475019yhh.2.gmail; Mon, 04 Jun
 2012 23:42:18 -0700 (PDT)
Received: by 10.236.76.133 with SMTP id b5mr16353548yhe.0.1338878538054;
        Mon, 04 Jun 2012 23:42:18 -0700 (PDT)
Received: by 10.236.76.133 with SMTP id b5mr16353546yhe.0.1338878538034;
        Mon, 04 Jun 2012 23:42:18 -0700 (PDT)
Return-Path: <svenpa...@google.com>
Received: from mail-gh0-f177.google.com (mail-gh0-f177.google.com [209.85.160.177])
        by gmr-mx.google.com with ESMTPS id v25si525766yhm.0.2012.06.04.23.42.18
        (version=TLSv1/SSLv3 cipher=OTHER);
        Mon, 04 Jun 2012 23:42:18 -0700 (PDT)
Received-SPF: pass (google.com: domain of svenpa...@google.com designates 209.85.160.177 as permitted sender) client-ip=209.85.160.177;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of svenpa...@google.com designates 209.85.160.177 as permitted sender) smtp.mail=svenpa...@google.com; dkim=pass header...@google.com
Received: by ghbf11 with SMTP id f11so3825038ghb.36
        for <v8-users@googlegroups.com>; Mon, 04 Jun 2012 23:42:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=google.com; s=20120113;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :x-system-of-record;
        bh=YGkQSr8OYXGNRTXtx05INujEFNJT3EsYZUpWcozP+cQ=;
        b=iXYoi/2CcS+c4LFKUD0xd3tiBD390xGYSq8Glywe+0JeFwB/DezyY1Vaz1JJtj7sL/
         E3jJS/33Cq7XEscm2apENvgcp0lWbsylC0eQX6Ry/rITkHqbn0YNYPk/gU5kEtCIRPUA
         NKb9NUf/I2cxSpZkY65+2GDmbeESDF6w+4CRzlgoeL0tcBk3HFcIxY07wkmfFqvis6FC
         4/rAWHPb6M1sWeCUiirs2lU6JmeEKG1oyOoFAlLG+i0a2bP+9gqD1pcVwexRFzZ2JTvB
         aYx9uqvnQpHtANnMiqCs3XBB6C5y36fHe/YzhBMxVciCv1I5NNM46BqgTRzeHdq+QZ3P
         eBrg==
        d=google.com; s=20120113;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :x-system-of-record:x-gm-message-state;
        bh=YGkQSr8OYXGNRTXtx05INujEFNJT3EsYZUpWcozP+cQ=;
        b=dvMvdaNKoWifwM7VocXR+flhvOwjy8VEHlXiCcR+nX/uciEK4xDKOH/DI5ONE2ng/Y
         xYj4n2tmp+b98cIXaMtWiYc/5nub16cVBS3DHzlrzniuRx+81PNWYGwTer/J+Wt6+BgU
         yhukSrHHozSUVaw0JgEc4vRtbj1BAF8b8ofyhe4carjCGZWybz1OrEpdXCOb4vvzaPHb
         Aud1wH3EVVdLy30a+PH8ye2GGJEBOXq+B9CJJ+KgoW1e2Bha2S3YmlNaE9zK+QK0WO3r
         JNROGdRkkQudrqKCEXpVDQkm/2WkkGbVu2Oo+1vpjut2fwsYuZSB5YA4Wuz7wrughaHw
         TeGw==
Received: by 10.50.41.165 with SMTP id g5mr992474igl.13.1338878537833;
        Mon, 04 Jun 2012 23:42:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.41.165 with SMTP id g5mr992470igl.13.1338878537758; Mon, 04
 Jun 2012 23:42:17 -0700 (PDT)
Sender: svenpa...@google.com
Received: by 10.231.51.95 with HTTP; Mon, 4 Jun 2012 23:42:17 -0700 (PDT)
In-Reply-To: <CAMs+Dq+R5nrMDMAMtpNBb1W1xMbV+QP2VrNNJHud0NybHs=...@mail.gmail.com>
References: <69fc4878-4170-41ee-99a5-f30b05005146@googlegroups.com>
	<CAOOCM2GHENwKHeYXoJruY4r2A-QTLiwVzXtzhs+fEWprC_p...@mail.gmail.com>
	<CAMs+Dq+R5nrMDMAMtpNBb1W1xMbV+QP2VrNNJHud0NybHs=...@mail.gmail.com>
Date: Tue, 5 Jun 2012 08:42:17 +0200
Message-ID: <CAOOCM2H2KtHtd4dbGUEukZrA0ToPcJzQdbWhhZci9XE1_O+...@mail.gmail.com>
Subject: Re: [v8-users] Does using delete keyword effect v8 optimizations of
 an object?
From: Sven Panne <svenpa...@chromium.org>
To: v8-users@googlegroups.com
Content-Type: multipart/alternative; boundary=14dae9340f6fa3f68304c1b3f307
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQlLyHQbySpv+nIQnwy2cZeIsP3xrXuPRESgt23YVrB1saYA4sUpE03qhgtz+FCRVix/5i0WUjrDht9ArBEtOwg9kvN2ZjhXho2usxDv/zeFUKmFr1exuVJ2rVu1IRAu40zjuwyxL1pTDEpJicSB8QbMGVJxMQ==

--14dae9340f6fa3f68304c1b3f307
Content-Type: text/plain; charset=ISO-8859-1

When you are using an object as a hash map, using delete is OK, because
then the object is very probably already in dictionary (= hash map) mode.
Playing GC by hand is not necessary and almost always the wrong thing,
anyway.

Is there a semantic reason for the structuring of the keys or do you
intentionally want to use a trie? If the keys are conceptually flat, you
can perhaps get better performance by just letting the JavaScript engine do
the hashing of the flat keys. Mixing hashing and tree structures is often
not a good idea: IIRC, there is an exercise in one of the classic Knuth
books where you have to prove that a "clever" hash table with binary trees
as buckets is worse than a simpler hash table with some probing strategy or
linear chaining (don't remember).

What is a "big integer set implementation"?

Cheers,
   S.

--14dae9340f6fa3f68304c1b3f307
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

When you are using an object as a hash map, using delete is OK, because the=
n the object is very probably already in dictionary (=3D hash map) mode. Pl=
aying GC by hand is not necessary and almost always the wrong thing, anyway=
.<div>
<br></div><div>Is there a semantic reason for the structuring of the keys o=
r do you intentionally want to use a trie? If the keys are conceptually fla=
t, you can perhaps get better performance by just letting the JavaScript en=
gine do the hashing of the flat keys. Mixing hashing and tree structures is=
 often not a good idea: IIRC, there is an exercise in one of the classic Kn=
uth books where you have to prove that a &quot;clever&quot; hash table with=
 binary trees as buckets is worse than a simpler hash table with some probi=
ng strategy or linear chaining (don&#39;t remember).</div>
<div><br></div><div>What is a &quot;big integer set implementation&quot;?</=
div><div><br></div><div>Cheers,</div><div>=A0 =A0S.</div><div><br></div>

--14dae9340f6fa3f68304c1b3f307--