Skip to content

Consider Impact of Separate Data Structure used by DefaultOpEnvironment.adaptOp #48

@gselzer

Description

@gselzer

DefaultOpEnvironment.adaptOp() obtains its set of adapt Ops simply by requesting all of them from the opCache. As scijava-ops builds a larger collection of adapt Ops, sorting through this collection to find the adapt Op needed becomes a bigger and bigger ask.

It might then be worthwhile to create a second data structure (most likely a Map<Class<?>, Set<OpInfo>>) to store all adapt OpInfos corresponding to a certain op type. For example, this Map might contain a Set of all OpInfos corresponding to the adapt Ops that can adapt to Functions, Computer.Arity0s, etc. and would thus eliminate the numerous checks against adapt Ops that give you Inplaces when you are looking for some BiFunction.

It is worth considering, however, how useful such an addition might be. When would we create it? It would be efficient to create such a structure during the initOpCache method, but does it make sense to create it there? Only if this structure is considered part of the opCache. Are ops adapted enough (per OpEnvironment) for this to make a significant increase in efficiency? @ctrueden do you have any intuition on this?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions