harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deven You <devyo...@gmail.com>
Subject Re: Security Performance issue
Date Thu, 22 Jul 2010 10:42:37 GMT
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.

2010/7/22 Regis <xu.regis@gmail.com>

> 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:
>> <code>
>> ...
>> 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" );
>> ...
>> </code>
>>
>> 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<xu.regis@gmail.com>  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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message