Speed up OpenSAML initialization ?

[Brent Putman]

On 2/27/15 4:04 PM, Tom Zeller wrote:
> On Fri, Feb 27, 2015 at 2:57 PM, Brent Putman <putmanb at georgetown.edu> wrote:
>> Not to sound flippant, but: how old is your workstation/laptop.  :-)
> I'm using a late 2012 Mac Mini, maxed out.

Ok, fairly recent, sounds like it nominally ought to be ok.  I don't
know anything about that hardware (CPU, etc), but...


> In Eclipse, GlobalAlgorithmRegistryInitializer.init() takes ~5s. To
> get that number I added a log statement at the beginning and end of
> that method, and I'm running the testbed.

That's really a big difference.   I started to say that maybe the Mac
Mini CPU isn't optimized very well for crypto or something... but the
AlgorithmRegistry runtime tests aren't really even doing any actual
crypto AFAIK.  They just attempt to obtain instances of the relevant
JCA service class, e.g.  Cipher.getInstance(...),
Signature.getInstance(...), etc.   Didn't think that involved crypto
ops per se, but maybe I'm wrong.  Maybe it internally inits some
crypto-relevant structures which are optimized if you have certain CPU
features, a coprocessor, etc.

So I really don't know why it's taking that long on your machine.  Did
you forget to engage the Turbo mode?  :-)  [1]


[1] In the 90s GU used to buy desktop PCs on the cheap from a local
company founded by a former student.  They had sort of a "home built"
quality to them.  They had a big 'turbo' button on the front of the
chassis.  Turns out it wasn't actually hooked up to anything, and I
don't even really know what it was intended to support.  But users
would always ask about it and/or claim that things should be faster
because they had "turbo mode" on.  I am not making this up.

 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20150227/1b0b0a09/attachment.html