EL handling null references

[Craig Longman <cr...@begeek.com>]

for anyone who has lots'o'EL experience, i'm trying to figure out the
best way to handle potentially null references in EL.  the basic
scenario is i have a variable that is probably set, and i want to do
three different things;
2) if a prop of a variable == a prop of a list object  (80%)
1) if a variable == a list object (15%)
3) if a variable doesn't exist (5%)

now, like most programming optimizations, i understand that the general
rule is that it depends on most used code paths, so i have estimated the
likeliness of each path.  so, given all that, my question.

how expensive is it to have a null referenced in EL?  i would like to do
this:

<c:choose>
 <c:when test="${root_var.name == item.category.name}">
  80% case
 </c:when>
 <c:when test="${root_var == item.category}">
  15% case
 </c:when>
 <c:otherwise>
  5% case (root_var == null, i _know_ there should be a match)
 </c:otherwise>
</c:choose>

this would seem like a good order to process, IF the references to
root_var when it doesn't exist are very light.  if it is expensive, then
one really should check root_var for null first, even though it is the
least likely case.

i hope all this makes sense, and i understand that i might be splitting
hairs here, but i really do prefer to write things for max performance,
and i cannot figure out from the jstl source code just how expensive an
EL null reference is.  i'm setting up some benchmarking pages to test
things also, but i would love to have some 'gut feelings' from EL
experts.

thanks,

-- 

    CraigL->Thx();
    Be Developer ID: 5852

Re: EL handling null references

[Craig Longman <cr...@begeek.com>]

On Sun, 2002-09-15 at 15:18, Shawn Bayern wrote:
> I'm not sure I fully understand what you're asking; what precisely do you
> mean when you wonder whether "references to root_var when it doesn't exist
> are very light"?  In general, the expression ${a.b} will not be expensive
> if 'a' results in null; it'll be less expensive than ${a.b} when 'a' is
> *not* null, for the latter situation requires a property lookup, while the
> former can immediately return.

ok, this makes sense.  i wasn't sure if EL assumed that variables would
contain reasonable values and just let a NullPointerException tell it
otherwise.  if that were the case, then it seemed prudent to handle
those cases first.  from what you're saying though, ${a.b} is 'light' in
processing time when a is null, so it makes sense to simply allow that
to fall through, seeing as thats the uncommon case.

thanks again.

-- 

    CraigL->Thx();
    Be Developer ID: 5852

Re: EL handling null references

[Shawn Bayern <ba...@essentially.net>]

On 15 Sep 2002, Craig Longman wrote:

> for anyone who has lots'o'EL experience, i'm trying to figure out the
> best way to handle potentially null references in EL.  the basic
> scenario is i have a variable that is probably set, and i want to do
> three different things;
> 2) if a prop of a variable == a prop of a list object  (80%)
> 1) if a variable == a list object (15%)
> 3) if a variable doesn't exist (5%)
> 
> now, like most programming optimizations, i understand that the general
> rule is that it depends on most used code paths, so i have estimated the
> likeliness of each path.  so, given all that, my question.

In general, I'd recommend empirical testing on at least one environment
before spending too much time considering how to order 'if' statements in
your code.  The difference is likely to be very small, and a smart JIT
could even optimize it away (though this case is moderately tricky since
there is indeed a well-defined order of execution and each conditional
evaluation can have side effects).

> how expensive is it to have a null referenced in EL?  i would like to do
> this:
> 
> <c:choose>
>  <c:when test="${root_var.name == item.category.name}">
>   80% case
>  </c:when>
>  <c:when test="${root_var == item.category}">
>   15% case
>  </c:when>
>  <c:otherwise>
>   5% case (root_var == null, i _know_ there should be a match)
>  </c:otherwise>
> </c:choose>
> 
> this would seem like a good order to process, IF the references to
> root_var when it doesn't exist are very light.  if it is expensive,
> then one really should check root_var for null first, even though it
> is the least likely case.

I'm not sure I fully understand what you're asking; what precisely do you
mean when you wonder whether "references to root_var when it doesn't exist
are very light"?  In general, the expression ${a.b} will not be expensive
if 'a' results in null; it'll be less expensive than ${a.b} when 'a' is
*not* null, for the latter situation requires a property lookup, while the
former can immediately return.

> i hope all this makes sense, and i understand that i might be
> splitting hairs here, but i really do prefer to write things for max
> performance, and i cannot figure out from the jstl source code just
> how expensive an EL null reference is.  i'm setting up some
> benchmarking pages to test things also, but i would love to have some
> 'gut feelings' from EL experts.

If it concerns you, then the ordering that you have above is fine.  It
saves an extra EL evaluation 20% of the time, on average.

-- 
Shawn Bayern
"JSTL in Action"   http://www.jstlbook.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>