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

Vitali Yemialyanchyk (JIRA) jira-events at lists.jboss.org
Wed Jul 20 11:21:23 EDT 2011


    [ https://issues.jboss.org/browse/JBIDE-9372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615467#comment-12615467 ] 

Vitali Yemialyanchyk commented on JBIDE-9372:
---------------------------------------------

Yahor, one more thing... It would be nice if you will use one code style for all over the code - Eclipse build-in code style is a good thing - only possible to use more long lines, for example 120 symbols. Of course one code style does not allow to developers express his individuality, but it allows others easy read code...
I do not know is your components dev. politics allows this - reformat all VPE code at once - or your prefer express your individuality... As I think VPE community ask for "reformat" decision.

> 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.
> the same for function ElService -> replaceCustomAttributes
> Jsf2ResourceUtil.processExternalContextPath & Jsf2ResourceUtil.processRequestContextPath - it is possible to optimize both of these functions... Example how should be:
> public static String processRequestContextPath(String value) {
>  return jsfRequestContextPath.matcher(value).replaceFirst("");
> }
> and task for developers - find arguments - why it has mach-mach better performance if we call this function several 1000 of times...
> other detail which I admit in ElService -> replaceElAndResources - why you guy do not use intermediate variables?
> your code snippet:
> >>>>
> if((pageContext.getVisualBuilder().getCurrentIncludeInfo()==null) || !(pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage() instanceof IFile)) {
> return rst;
> }
> final IFile file = (IFile) pageContext.getVisualBuilder().getCurrentIncludeInfo().getStorage();
> >>>>
> my code snippet:
> >>>>
> final VpeIncludeInfo vii = pageContext.getVisualBuilder().getCurrentIncludeInfo();
> if (vii == null || !(vii.getStorage() instanceof IFile)) {
> return rst;
> }
> final IFile file = (IFile)vii.getStorage();
> >>>>
> I advise and recommend use intermediate variables! You will reduce functions call (in my example only 1 time instead of 3), you will reduce code, you make code more readable.
> - the same for ElService -> isELNode

--
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