-----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.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlayJRcACgkQ9CaO5/Lv0PDawQCfbvmI12paCRrzqh4sArOg+ImQ
MHIAoIMAiGTtFXzL/GEYhHLbLvVF1uVY
=tfnY
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
