Uploaded image for project: 'ZK'
  1. ZK
  2. ZK-2542

@converter causes a big performance issue on the nested children binding

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 8.0.0
    • Component/s: Databind 2
    • Labels:
      None

      Description

      The main issue is about the EL resolver to evaluate the expression for about 100,000 times. 100 * 100 * 5 (@converter parameters) * 2 (ReferenceBinding for converter parameters)
      For example,

      <zk xmlns:x="xhtml">
      	<zscript><![CDATA[
      	public class MyVM {
      		public void setChildren(List children) {}
      		public List getChildren() {
      			int size = 100;
      			List s = new ArrayList(size);
      			for (int i = 0; i < size; i++)
      				s.add(i);
      			return s;
      		}
      		public void setConcatConverter(Converter c) {}
      		public Converter getConcatConverter() { return new ConcatConverter();}
      		class ConcatConverter implements Converter {
      		    public Object coerceToUi(Object val, Component comp, BindContext ctx) {
      		    	return "";
      		    }
      		    public Object coerceToBean(Object val, Component comp, BindContext ctx) {
      		    	return null;
      		    }
      		}
      	}
      	]]></zscript>
      	<div id="bind" apply="org.zkoss.bind.BindComposer"
      		viewModel="@id('vm') @init('MyVM')">
      		<x:table id="host" border="1" children="@load(vm.children)">
      			<template name="children" var="r">
      				<x:tr children="@load(vm.children)">
      					<template name="children" var="gb">
      						<x:td>
      							<label
      								style='@load(vm.children) @converter(vm.concatConverter,x=r,y=gb,z=gb, format="background:rgb(%s,%s,%s)")' />
      						</x:td>
      					</template>
      				</x:tr>
      			</template>
      		</x:table>
      	</div>
      </zk>
      

        Activity

        Hide
        jumperchen jumperchen added a comment - - edited

        To solve this is to provide a smart EL resolver, such as cacheable or runtime variable scope to reduce the evaluation process.

        Show
        jumperchen jumperchen added a comment - - edited To solve this is to provide a smart EL resolver, such as cacheable or runtime variable scope to reduce the evaluation process.
        Hide
        jumperchen jumperchen added a comment -

        BindUiLifeCycle#handleComponentAttached() didn't make a self protection to skip the child which has been handled by children binding.
        So the total evaluations are 100 * 100 * 5 * 2 * depth (in template, in this case is 3 [tr > td > label])

        Show
        jumperchen jumperchen added a comment - BindUiLifeCycle#handleComponentAttached() didn't make a self protection to skip the child which has been handled by children binding. So the total evaluations are 100 * 100 * 5 * 2 * depth (in template, in this case is 3 [tr > td > label] )
        Hide
        jumperchen jumperchen added a comment -

        Bug fixed since 9/8/2015

        Show
        jumperchen jumperchen added a comment - Bug fixed since 9/8/2015

          People

          • Assignee:
            jumperchen jumperchen
            Reporter:
            jumperchen jumperchen
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 2 hours
              2h