[jbosstools-issues] [JBoss JIRA] Updated: (JBIDE-9372) VPE has a serious performance drawback for rather big pages

Vitali Yemialyanchyk (JIRA) jira-events at lists.jboss.org
Wed Jul 20 08:36:24 EDT 2011


     [ https://issues.jboss.org/browse/JBIDE-9372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vitali Yemialyanchyk updated JBIDE-9372:
----------------------------------------

    Description: 
rather big pages - in general dev project this is normal page size...
My proposition for VPE developers pay attention to performance. This is example place to enhancement: 

VpeNodeInvocationHandler -> invoke -> for every get attribute call in VPE templates - call this:

ElService.getInstance().replaceElAndResources(this.pageContext, toReplace);

ElService -> replaceEl -> getAllResources - array creation (!) and then 
ElService -> replaceEl -> replace - clone array (!) and then array sort (!)

FOR EVERY sourceNode.getAttribute("...")
in function VpeAbstractTemplate -> public VpeCreationData create(VpePageContext pageContext, Node sourceNode, nsIDOMDocument visualDocument) {...}

array create and sort operations should be performed only one time!

moreover it is possible to bust performance of ElService -> replaceEl -> replace -> for cycle
here in cycle you create two help strings dollarEl & sharpEl - and then check contains - very time consuming and unnecessary things in case if resourceString.length() < rf.getLocation().length() - just this simple check should bust function performance significantly.


  was:
rather big pages - in general dev project this is normal page size...
My proposition for VPE developers pay attention to performance. This is example place to enhancement: 

VpeNodeInvocationHandler -> invoke -> for every get attribute call in VPE templates - call this:

ElService.getInstance().replaceElAndResources(this.pageContext, toReplace);

ElService -> replaceEl -> getAllResources - array creation and then 
ElService -> replaceEl -> replace - array sort

FOR EVERY sourceNode.getAttribute("...")
in function VpeAbstractTemplate -> public VpeCreationData create(VpePageContext pageContext, Node sourceNode, nsIDOMDocument visualDocument) {...}

array create and sort operations should be performed only one time!




> VPE has a serious performance drawback for rather big pages
> -----------------------------------------------------------
>
>                 Key: JBIDE-9372
>                 URL: https://issues.jboss.org/browse/JBIDE-9372
>             Project: Tools (JBoss Tools)
>          Issue Type: Enhancement
>          Components: Visual Page Editor core, Visual Page Editor Templates
>    Affects Versions: 3.3.0.M3
>            Reporter: Vitali Yemialyanchyk
>            Assignee: Yahor Radtsevich
>            Priority: Minor
>             Fix For: 3.3.0.M3
>
>
> rather big pages - in general dev project this is normal page size...
> My proposition for VPE developers pay attention to performance. This is example place to enhancement: 
> VpeNodeInvocationHandler -> invoke -> for every get attribute call in VPE templates - call this:
> ElService.getInstance().replaceElAndResources(this.pageContext, toReplace);
> ElService -> replaceEl -> getAllResources - array creation (!) and then 
> ElService -> replaceEl -> replace - clone array (!) and then array sort (!)
> FOR EVERY sourceNode.getAttribute("...")
> in function VpeAbstractTemplate -> public VpeCreationData create(VpePageContext pageContext, Node sourceNode, nsIDOMDocument visualDocument) {...}
> array create and sort operations should be performed only one time!
> moreover it is possible to bust performance of ElService -> replaceEl -> replace -> for cycle
> here in cycle you create two help strings dollarEl & sharpEl - and then check contains - very time consuming and unnecessary things in case if resourceString.length() < rf.getLocation().length() - just this simple check should bust function performance significantly.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the jbosstools-issues mailing list