[
https://issues.jboss.org/browse/JBIDE-9372?page=com.atlassian.jira.plugin...
]
Vitali Yemialyanchyk commented on JBIDE-9372:
---------------------------------------------
one more additional thing - I've review VpePageContext and see obvious need to have
point to extend this class functionality, i.e. it would be nice if you add variable:
protected Map<String, Object> extMap;
so you can put ElService array here, you can get rid of customElementsAttributes - just
store it's values as one item of extMap. i.e. this could be a very useful thing - this
extMap will allows for templates pass information from one to another during page
rendering process. Intention of customElementsAttributes is very-very narrow - it allows
only strings bypass.
VpePageContext -> processDisplayEvents() - is a static function by it's intention.
VpePageContext ->
private nsIDOMNode currentVisualNode;
- is a very specific variable for VpeDataTableCreator template - extMap - is more
preferable place for such template specific variables.
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