Hi Chris,
Am 03.02.2016 um 17:04 schrieb Christopher Schultz:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rainer,
On 2/3/16 10:48 AM, Rainer Jung wrote:
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
Is the stack trace of the current implementation important when that
Error (subclass) is thrown? If the stack trace is important to be
filled-in at that earlier time, then this is a complex issue. If
nobody cares what the stack trace says, I'm +1 for only instantiating
the Error when it needs to be thrown.
The stack should be nearly the same except for some <init> on top
currently and jj_scan_token() when instantiated on demand. Is it
important? I'd say the frames lower down should help people to find
where in the app they create an EL which on parsing throws the error.
I'd be interested if there's an expectation whether ELParser object
creation could happen frequently or should happen rarely (after an app
has reached steady state).
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
