Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 52514 invoked from network); 24 Jul 2010 11:36:16 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 24 Jul 2010 11:36:16 -0000 Received: (qmail 29207 invoked by uid 500); 24 Jul 2010 11:36:16 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 28973 invoked by uid 500); 24 Jul 2010 11:36:14 -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 28964 invoked by uid 99); 24 Jul 2010 11:36:13 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 24 Jul 2010 11:36:13 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of devyoudw@gmail.com designates 209.85.213.177 as permitted sender) Received: from [209.85.213.177] (HELO mail-yx0-f177.google.com) (209.85.213.177) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 24 Jul 2010 11:36:05 +0000 Received: by yxj4 with SMTP id 4so4339552yxj.36 for ; Sat, 24 Jul 2010 04:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=JoAza6ckgu8RMVwIGDKNW5M1lsReG1c1nlfqyTWXs5k=; b=wZ9dq0x0jhABE47dWpKgMwOc2pXR0rcHapvuqw0koMaHDzNFxQXyyntYK1jGTjwRlq o+lBIgzROOVd/v0lUpwc+jYl4Dida5nXxiEx8WxrnLhZfWBele4opf834rkvKI3PsDVy 1yD5BsaFuKqwCRL/U34z2Kme416EkEq85w4pk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=DxYsx35d1GzJhE1eGuCE6wFXOPo6n/7gtpg2mmQgSADC1wAXyxLxr4Sjod4DLs7TtY 1yjf8spzB/MqcSCEBwcUC41NoMVKPUcJPZSZpblSQlrVqlZmpCNOZVROWGtddzf/etUM 8tjd0hNMyA/98DCAYH7uKNSdb7PUTAFCdyM9s= MIME-Version: 1.0 Received: by 10.100.228.8 with SMTP id a8mr1398183anh.26.1279971344265; Sat, 24 Jul 2010 04:35:44 -0700 (PDT) Received: by 10.100.110.12 with HTTP; Sat, 24 Jul 2010 04:35:44 -0700 (PDT) In-Reply-To: References: <4C47DEB0.3010301@gmail.com> <4C481048.5070101@gmail.com> <4C49BE81.3070300@gmail.com> Date: Sat, 24 Jul 2010 19:35:44 +0800 Message-ID: Subject: Re: Security Performance issue From: Deven You To: dev@harmony.apache.org Content-Type: multipart/alternative; boundary=00163691fec24c3273048c208dee X-Virus-Checked: Checked by ClamAV on apache.org --00163691fec24c3273048c208dee Content-Type: text/plain; charset=ISO-8859-1 I am not sure which classes are loaded during the Security.getProvider() for both harmony and RI, and I found another interesting thing that is the time spent on Class.newInstance() on both harmony and RI are almost the same though the time on the Class.forName() are different so much. 2010/7/24 Deven You > Hi Tim > Actually I mean Class.forName() in theSecurity.getProvider() invocation > stack. So I can be sure our security implementation loads much more classes > than RI's one. Thanks for your question, I think on the above mail I talked > so generally. > > 2010/7/24 Tim Ellison > > On 22/Jul/2010 11:42, Deven You wrote: >> > Profiling results show RI's Class.forName() takes much less time than >> > Harmony ones. It may caused by harmony load too much classes, maybe we >> need >> > consider load providers only needed. >> >> You mean "Class.forName()" loading the same class (i.e. the time to >> search and load a given class), or are you talking about the load/init >> time for BouncyCastle's providers compared to the RI providers? >> >> Regards, >> Tim >> >> > 2010/7/22 Regis >> > >> >> On 2010-07-22 14:26, Ray Chen wrote: >> >> >> >>> Hi Regis, >> >>> You mean init these providers is slow, right? But actually we should >> >>> not init unnecessary providers. >> >>> >> >>> I added some info in our code as following and you can see init these >> >>> provider takes most of the time: >> >>> >> >>> ... >> >>> long start = System.currentTimeMillis(); >> >>> p = (Provider) Class.forName(providerClassName.trim(), true, >> >>> cl).newInstance(); >> >>> System.out.println("init " + p.getName() + "takes " + >> >>> (System.currentTimeMillis()-start) + " ms"); >> >>> providers.add(p); >> >>> providersNames.put(p.getName(), p); >> >>> long start2 = System.currentTimeMillis(); >> >>> initServiceInfo(p); >> >>> System.out.println("init services of " + p.getName() + "takes " + >> >>> (System.currentTimeMillis() - start2) + " ms" ); >> >>> ... >> >>> >> >>> >> >>> And the output is: >> >>> init DRLCertFactorytakes 226 ms >> >>> init services of DRLCertFactorytakes 6 ms >> >>> init Cryptotakes 1 ms >> >>> init services of Cryptotakes 1 ms >> >>> init HarmonyJSSEtakes 0 ms >> >>> init services of HarmonyJSSEtakes 1 ms >> >>> init BCtakes 204 ms >> >>> init services of BCtakes 11 ms >> >>> >> >>> >> >>> On Thu, Jul 22, 2010 at 2:01 PM, Regis wrote: >> >>> >> >> init DRLCertFactorytakes 226 ms >> >> init BCtakes 204 ms >> >> >> >> It seems provider itself spent a lot of time. >> >> >> >> Have you compared time of following code against RI and Harmony with >> the >> >> same provider class name? >> >> >> >> >> >> (Provider) Class.forName(providerClassName.trim(), true, >> cl).newInstance(); >> >> >> >> If there were still huge gaps, I think it's not caused by way we load >> >> providers, maybe there are other performance hole in some places. I >> agree >> >> that the way loading providers still have room to improve, but we need >> to >> >> find out and shoot the most outstanding issue first. >> >> >> >> >> >> >> >> -- >> >> Best Regards, >> >> Regis. >> >> >> > >> > > --00163691fec24c3273048c208dee--