From dev-return-36382-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Wed Mar 11 08:50:27 2009 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 70511 invoked from network); 11 Mar 2009 08:50:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Mar 2009 08:50:27 -0000 Received: (qmail 6457 invoked by uid 500); 11 Mar 2009 08:50:21 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 6416 invoked by uid 500); 11 Mar 2009 08:50:21 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 6383 invoked by uid 99); 11 Mar 2009 08:50:21 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Mar 2009 01:50:21 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of xu.regis@gmail.com designates 74.125.46.152 as permitted sender) Received: from [74.125.46.152] (HELO yw-out-1718.google.com) (74.125.46.152) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Mar 2009 08:50:10 +0000 Received: by yw-out-1718.google.com with SMTP id 4so359199ywq.0 for ; Wed, 11 Mar 2009 01:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=sU6I3bzKTt9Z8oOFTDSE9i8rwuKjnBALAwKo4AYWLZY=; b=qt/tNzzcwJGNJjW1ZmCyQ7DTG7kohKfS+AvkFCrUxmnJHaQoDrFnK3GjX6nnl5FNlN jN6E2l4nvrWqnFgvM3yGo5TXqgAGeglpz+N9I8uCa2ZPpBcircYeCt0s4ZyntrDIaqlT qKGkgKiutt+ghZdQk41kDYN4s22FfotNzn11g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=DoiwtVUklgeod4MMBk3poOBEajrWt5GuHBmr22S6feqKyLemOSemy76mR7N/tPSeub VVd35s+2bN7N8aJC3P/72gH07ZUfGh9dSkY1Gv21OhkW4Md8X+qLPlJmmrZZqIdVLv/6 W7Wy9AU13CPzkMNQUkCgDcYJpDjCyUAnGB4sM= Received: by 10.100.120.19 with SMTP id s19mr5248397anc.149.1236761389715; Wed, 11 Mar 2009 01:49:49 -0700 (PDT) Received: from ?9.123.237.97? ([220.248.0.145]) by mx.google.com with ESMTPS id d21sm705530and.46.2009.03.11.01.49.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Mar 2009 01:49:49 -0700 (PDT) Message-ID: <49B77B26.40109@gmail.com> Date: Wed, 11 Mar 2009 16:49:42 +0800 From: Regis User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: dev@harmony.apache.org Subject: [classlib] performance of java.io.File Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hi all, Recently I found our java.io.File implementation is obviously slower than RI on Windows, especially when a SecurityManager is installed. Testing with following simple test case: File file = new File("FilePerTest.java"); long start = System.currentTimeMillis(); for (int i = 0; i < 40000; ++i) { file.isFile(); file.exists(); file.canRead(); } long end = System.currentTimeMillis(); hy without SecuirtyManager ri without SecuirtyManager 6766ms 1203ms after installing a SecuirtyManager System.setSecurityManager(new SecurityManager()); hy with SecuirtyManager ri with SecuirtyManager 54406ms 4078ms We can see the gap is huge. After some investigations, I found two problems in Harmony implemenation: 1. Harmony used File.getCanonicalPath() in FilePermission, which is very slow. Because if a SecurityManager was installed, every file operation would be check by FilePermission, that cause the huge gap (54406ms compare to 4078ms). 2. in file native code file.c, ioh_convertToPlatform is called by every method which "convert all separators to the proper platform separator and remove duplicates on non POSIX platforms." (copied from comment of method), that is exactly what File.fixSlashes did, I think they are duplicated. I have created a JIRA HARMONY-6116 to track this issue, and sub-task HARMONY-6117 for 1. A prototype patch already attach to HARMONY-6117, your comments and suggestions are welcome. -- Best Regards, Regis.