Hi there,
ELParser has a field named jj_ls of type LookaheadSuccess which extends
Error. It is created during each instantiation of an ELParser object.
Creating an Error is quite slow, because e.g. it calls
java.lang.Throwable.fillInStack() during init.
This jj_ls is only used once in jj_scan_token() where it is thrown in
case of certain condition, see line 2985:
2968 private boolean jj_scan_token(int kind) {
2969 if (jj_scanpos == jj_lastpos) {
2970 jj_la--;
2971 if (jj_scanpos.next == null) {
2972 jj_lastpos = jj_scanpos = jj_scanpos.next =
token_source.getNextToken();
2973 } else {
2974 jj_lastpos = jj_scanpos = jj_scanpos.next;
2975 }
2976 } else {
2977 jj_scanpos = jj_scanpos.next;
2978 }
2979 if (jj_rescan) {
2980 int i = 0; Token tok = token;
2981 while (tok != null && tok != jj_scanpos) { i++; tok = tok.next; }
2982 if (tok != null) jj_add_error_token(kind, i);
2983 }
2984 if (jj_scanpos.kind != kind) return true;
2985 if (jj_la == 0 && jj_scanpos == jj_lastpos) throw jj_ls;
2986 return false;
2987 }
This is generated code and it is the only place were jj_ls is being used.
I noticed this situation because I'm doing a performance analysis of an
application. I wonder whether creating this jj_ls for each new ELParser
instance in advance is the right thing to do. One could also put the
burden on the usage side, e.g. generating it when it is needed to be
thrown. Unfortunately I don't know enough about the typical runtime
details of ELParser. E.g. it might be that typically only few instances
of it are created because they get reused (which doesn't seem to be the
case, we only create and use it method local in
createNodeInternal.createNodeInternal()) or their results get cached
(which seems to be the case).
I'll have a look at how effective the caching is for the application in
question, but I'd be interested if there is an opinion whether the
pattern to create the Error object eagerly when creating the ELParser
object seems appropriate. No idea currently, how one would change it
though, because it is generated code.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
