You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Stefan Seifert (JIRA)" <ji...@apache.org> on 2014/10/28 16:53:33 UTC

[jira] [Created] (SLING-4112) Sling Models: Optimize performance when read sling models annotations

Stefan Seifert created SLING-4112:
-------------------------------------

             Summary: Sling Models: Optimize performance when read sling models annotations
                 Key: SLING-4112
                 URL: https://issues.apache.org/jira/browse/SLING-4112
             Project: Sling
          Issue Type: Improvement
          Components: Extensions
    Affects Versions: Sling Models Implementation 1.1.0
            Reporter: Stefan Seifert
            Priority: Minor
             Fix For: Sling Models Impl 1.2.0
         Attachments: 141028_adaptto_jprofiler_slingmodels.gif, 141028_adaptto_jprofiler_slingmodels_getannotation.gif

i did some first performance tests with a sling application that makes intensive usage of sling models to see where potential hotspots are that cost performance, esp. in area of sling models.

attached is a filtered view of a jprofile session showing only the method calls inside sling models implementation:
[^141028_adaptto_jprofiler_slingmodels.gif]

a good part of performance is spent on inspection the annotations of the sling models classes, a call graph of the first method: [^141028_adaptto_jprofiler_slingmodels_getannotation.gif]

i think this is especially the case because this inspection takes place on each adaptTo() call, although the underlying model class never changes when the OSGi bundle stays in place.

it should be possible to come up with an optimization caching the inspection results (which annotations exist on which fields/methods/types with which parameters), and doing only the injection part on each adaptTo() invocation. if the bundle changes the cache has to be cleared.

i will think about it the next days and perhaps come up with an implementation proposal.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)