From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12934 invoked by alias); 25 Jul 2007 15:39:45 -0000 Received: (qmail 12927 invoked by uid 22791); 25 Jul 2007 15:39:45 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 25 Jul 2007 15:39:42 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l6PFdciP014148; Wed, 25 Jul 2007 11:39:39 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l6PFdcaB009348; Wed, 25 Jul 2007 11:39:38 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l6PFdbgH027189; Wed, 25 Jul 2007 11:39:37 -0400 Message-ID: <46A76EDB.1080400@redhat.com> Date: Wed, 25 Jul 2007 15:39:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Mark Wielaard CC: frysk@sourceware.org Subject: Re: [patch] Stat vs slurp vs linux 2.6.22 References: <1185363024.3597.16.camel@dijkstra.wildebeest.org> <46A75077.2020706@redhat.com> <1185375592.3597.40.camel@dijkstra.wildebeest.org> In-Reply-To: <1185375592.3597.40.camel@dijkstra.wildebeest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q3/txt/msg00179.txt.bz2 Mark Wielaard wrote: > Hi Andrew, > > On Wed, 2007-07-25 at 09:30 -0400, Andrew Cagney wrote: > >>> It might make sense to rewrite slurp as a normal java class so these >>> cross C/Java error handling issues. Is there a reason for slurp to have >>> to be written in C/CNI? >>> >>> >> -> memory pressure; notice how it does a callback >> -> performance >> > > Interesting. It does feel a little like a premature optimization though, > seeing that we are finding bugs in it because of the Java/C/CNI mixture > of error and memory handling that are hard to track down. > > We're talking here about Scan, not slurp; the first implementation did use File et.al. It was changed from java to a builder to reduce memory pressure and produced a dramatic performance boost. Scan, by not double allocating memory read also keeps memory pressure down. Going forward, the less memory dropped on the floor by the core, the easier it will be to push more of this into C++. Andrew > >