[
https://issues.jboss.org/browse/JBIDE-9372?page=com.atlassian.jira.plugin...
]
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