From derby-dev-return-3629-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Sun May 01 07:18:51 2005 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 33996 invoked from network); 1 May 2005 07:18:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 May 2005 07:18:51 -0000 Received: (qmail 86076 invoked by uid 500); 1 May 2005 07:20:15 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 85924 invoked by uid 500); 1 May 2005 07:20:14 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Development" Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 85908 invoked by uid 99); 1 May 2005 07:20:14 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from smtp05.mrf.mail.rcn.net (HELO smtp05.mrf.mail.rcn.net) (207.172.4.64) by apache.org (qpsmtpd/0.28) with ESMTP; Sun, 01 May 2005 00:20:14 -0700 Received: from 205-178-43-242.s496.tnt1.sfrn.ca.dialup.rcn.com (HELO Nipper.rcn.com) (205.178.43.242) by smtp05.mrf.mail.rcn.net with ESMTP; 01 May 2005 03:18:45 -0400 Message-Id: <6.0.0.22.2.20050501000926.03180918@pop.rcn.com> X-Sender: swazoo@pop.rcn.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sun, 01 May 2005 00:18:41 -0700 To: "Derby Development" From: Jeffrey Lichtman Subject: Re: Optimal tuple memory representation In-Reply-To: <200505010319.11208.jean.morissette666@videotron.ca> References: <200505010319.11208.jean.morissette666@videotron.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N >I'm wondering if creating java object for each tuple and let the gc do its >work would be more performant than having a reusable ByteBuffer that contains >many raw tuples? What do you think? When we created Derby (nee Cloudscape), object instantiation and garbage collection were still quite expensive. We decided it would be cheaper to re-use objects such as data values and rows - this would avoid the problem of creating and destroying large numbers of objects when scanning through tables and indexes. Since then the memory management in most JVMs has gotten smarter, and if we were to start from scratch today we might not put so much emphasis on object re-use. For example, we might make data values and rows immutable, which would simplify the design of certain other parts of the system (e.g. code generation, some store interfaces, etc.). - Jeff Lichtman swazoo@rcn.com Check out Swazoo Koolak's Web Jukebox at http://swazoo.com/