Re: [udig-devel] UDig Rendering Performance

[Jody Garnett <jody.garnett@xxxxxxxxx>]

Excellent debugging Emily - as the australian's say "you are a champion" (trying to blend in with the natives).

So we got two options here for 1.3.2:

- Fix ResolveManager so its performance is not terrible; or

- disable the IResolveFactory contributions from the info tool plugin

Additional research provide inline …

Jody

On Tuesday, 28 August 2012 at 5:57 AM, Emily Gouge wrote:

The "real" plugin that is the source of the render slow down is the

net.refractions.udig.tool.info plugin.

The reason I thought the WMS render is the problem is because the

net.refractions.udig.tool.info requires the WMS renderer plugin so when

I removed the WMS renderer plugin I also removed this info plugin. This

requirement doesn't make sense to me but that is another issue.

Aside: It is because the WMS "GetFeatureInfo" method needs to know the *exact* "GetMap" request that was made in order to function. If we ever make a decent extension point for the "info tool" then we will move this work over to the WMS renderer plugin.

The info tool plugin causes rendering problems because it adds catalog resolvers.

As a part of rendering each IGeoResource is "resolved" to something.

This resolving process uses the ResolveManager.java class. The

ResolveManager goes through all catalog resolvers and tries to resolve them.

The majority of the time is spent in the isTargetTypeSupported(...)

methods on this line (196):

Class< ? > resolvedClass = classLoader.loadClass(resolveType);

Okay time for a sanity check. ResolveManager is a "port" of the same design as AdapterManager - and does not have this performance problem.

Looking at the internals of AdapterManager they keep a cache of Classes so they do not have to do any reflection at runtime. I have provided my own

comments below after reading the source code...

// Maps resolve class name --> Map (target class name --> factory instance )

Map adapterLookup;

// Maps factory instance -> Map (target class name --> target class )

Map classLookup;

Map classLookupLock;

// Map of Class -> Class[]

Map classSearchOrderLookup;

// Map full resolve class name  --> List of factories

Map factories;

Okay I am going to bang up an implementation of ResolveManager2 using something like the above (with full generics for sanity). If successful I will issue a pull request or something.

Jody