Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of xu.regis@gmail.com designates
 209.85.212.177 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=pjbTsj39XUq/RkfBijoA2RiocSAt0qfVGbJ22O/i8dCY9Js+lEtGQ07b3r4ish9YOl
         r2cOwAvcvhdqIHHz/AO3MPTEnkXY6feGxjCae8kkYKu8HZI9N0NNZcLhW5yU+tNaQbkc
         iJdauVpBtTe3C0DVcqIJUyneXJGd9r1hYkHMw=
Message-ID: <4C47DEB0.3010301@gmail.com>
Date: Thu, 22 Jul 2010 14:01:20 +0800
From: Regis <xu.regis@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: Security Performance issue
References: <AANLkTi=ELxFRa-ZE=gakM-SJPPZD2ynhKKSK2x0Cx61p@mail.gmail.com>
In-Reply-To: <AANLkTi=ELxFRa-ZE=gakM-SJPPZD2ynhKKSK2x0Cx61p@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 2010-07-22 13:07, Ray Chen wrote:
> Hi All,
> I found that our security implementation is much slower than RI's when
> get an algorithm instance.
> I have done some investigation and found that most time are consumed
> on loading and initialising providers.
> Following is the test cases and results to show this problem.
>
>                        RI5         |      RI6      |     Harmony5    |
>    Harmony6
> Testcase1[1]    78ms      | 90~100ms  |     450ms        |   475~490ms
> Testcase2[2]    75ms      |  85~91ms  |                       |
> Testcase3[3]                  |                 |   447~455ms    | 470~490ms
> Testcase4[4]    9~10ms  |   6ms         |                       |
> Testcase5[5]                 |                  |    448~462ms   |  479~501ms
> Testcase6[6]    9ms       |    8~10ms   |   448~459ms   |   481~490ms
>
> From[1], we can see our implementation is much slower than RI's when
> loading all the providers.
> Compare [2]&  [3], both loading JSSE provider, our implementation is
> much slower.
> Compare [2]&  [4], the time differs, which means RI can load providers
> one by one.
> Compare [1],[3]&  [5], we can see our implementation consumes almost
> same time whether it loads one or more providers.
> Form[6], I guess RI knows what services a provider provides so that it
> can just pick up the providers the application need.
>
> If you look into the Services.java, you will find that our
> implementation will load all the providers when this class is loaded
> even this application does NOT need some of providers.
> Then it put all the providers and services into a cache which can be
> called "pre-loading".
>
> Base on the above investigation, I suggest to change the "pre-loading"
> to "lazy-loading" if possible which means only loading necessary
> providers, no more, no less.
>
> But I found that it is very hard to achieve this target, because we
> don't know what services a provider provides before we load the
> provider.
> I don't know what RI does to achieve this.
> Maybe we can store the map relationships between these default
> providers and services to a file or internal cache table?
>
> Any comments or suggestions?
>
> Jimmy, Kevin,
> I talked to you about this issue before, feel free to fix me if
> anything is wrong.
> Or you can give more information about this issue.
>
> [1]
> public static void main(String[] args) {
>          long start = System.currentTimeMillis();
>          for (Provider p : Security.getProviders()) {
>              p.getServices();
>          }
>          System.out.println(System.currentTimeMillis() - start);
> }
>
> [2]
> public static void main(String[] args) throws NoSuchAlgorithmException {
>      long start = System.currentTimeMillis();
>      Security.getProvider("SUNJSSE");
>      System.out.println(System.currentTimeMillis() - start);
> }
>
> [3]
> public static void main(String[] args) throws NoSuchAlgorithmException {
>       long start = System.currentTimeMillis();
>       Security.getProvider("HarmonyJSSE");
>       System.out.println(System.currentTimeMillis() - start);
> }
>
> [4]
> public static void main(String[] args) throws NoSuchAlgorithmException {
>          long start = System.currentTimeMillis();
>          Security.getProvider("SUN");
>          System.out.println(System.currentTimeMillis() - start);
> }
>
> [5]
> public static void main(String[] args) throws NoSuchAlgorithmException {
>      long start = System.currentTimeMillis();
>      Security.getProvider("BC");
>      System.out.println(System.currentTimeMillis() - start);
> }
>
> [6]
> public static void main(String[] args) throws NoSuchAlgorithmException {
>      long start = System.currentTimeMillis();
>      MessageDigest.getInstance("SHA-1");
>      System.out.println(System.currentTimeMillis() - start);
> }

"Security.getProvider" at least has two steps: searching providers and 
initializing providers. Searching providers is implemented by Harmony, 
initializing is implemented by providers, from your test and data, we don't know 
which part is performance killer.

And BouncyCastle supports a lots of algorithms, I'm not sure if it support lazy 
loading.

-- 
Best Regards,
Regis.