Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Mon, 01 May 2006 07:16:13 -0700
From: Rick Hillegas <Richard.Hillegas@Sun.COM>
Subject: Re: Derbyall runtimes, 10.1, and Security Manager
In-reply-to: <44539A7C.3010008@amberpoint.com>
Sender: Richard.Hillegas@Sun.COM
To: derby-dev@db.apache.org
Message-id: <4456182D.5070907@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <44539A7C.3010008@amberpoint.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

Hi Bryan,

When playing around with individual tests--enabling and disabling the 
SecurityManager--I have noticed that our tests run considerably slower 
when launched under the SecurityManager. I don't have any sense of how 
much of the problem is just a tax we have to pay for security. Sounds 
like your experiments may have confirmed that the problem is not 
isolated to our test environment. It's definitely worth profiling this 
drag so that

1) we can factor security calls to the outer loop
2) we can appropriately set our customers' expectations

Regards,
-Rick

Bryan Pendleton wrote:

> I had occasion recently to be porting a few bug fixes from the
> trunk to 10.1, and so I happened to be running derbyall on 10.1.
>
> I don't really want to re-ignite the debate over derbyall runtime,
> but the difference in duration between a derbyall run on the
> trunk, and a derbyall run on 10.1, was really remarkable.
>
> Then, as part of working on DERBY-1229, I happened to be running
> a lot of interactive experiments both with and without the
> security manager. And I noticed that when I ran Derby code with
> the security manager enabled, the runtime speed was noticeably
> slower.
>
> So I'm wondering, is it possible that a significant portion of
> the derbyall slowdown in the trunk is due to running with the
> security manager enabled, and, if so, is there anything we can
> do with that knowledge?
>
> thanks,
>
> bryan
>