Re: Improving String.equals() implementation

Lew wrote:
Eric Sosman wrote:
[...]
I don't understand your objection. The methods are different
because the point of the exercise was to measure the performance
impact of their difference, as a follow-up to Lothar Kimmeringer's
point about the cost of a "redundant" instanceof test. If both
methods had (or both lacked) the test, what would be measured?

I didn't say that both methods should have the 'instanceof' test. Duhy.

I said they should have the same behaviors. The first implementation returns 'false' if the argument is a different type. The second one throws an exception if the types differ. The second method should catch the exception and return 'false'.

If one is considering an optimization for a project, one cannot consider "optimizations" that break contract behavior.

Lew, please don't dilute your considerable value with
gratuitous snarky nastiness.

It is true that one of the equals() methods in my code
was faulty, in that it would throw an exception if passed a
reference that was null or that targeted an object of the
wrong type. Yes, I could have embedded the thing in `try'
with a `return false' in the `catch' block. But what good
would that have done?

We all know -- I hope we all know -- that a `try' block
adds precisely nothing to the generated JVM instructions. It
is conceivable that the presence of code in the `catch' or
`finally' might possibly influence the JIT's translation of
bytecodes to opcodes, and my test would have been sharper if
I had chosen to worry about that. Sue me -- better yet, make
the correction and post your own results.

As for coping with actual thrown exceptions, that leads to
the tricky business of determining the likely proportion of
exception-throwing invocations. Such a determination would be
a research project requiring far more effort than I was willing
to spend on idle curiosity about a Usenet post. If your zeal
for knowledge exceeds mine, by all means get out there and do
some studies on the actual frequency of equals() calls with
null or cross-classed arguments. There's surely a scholarly
paper in it for anyone with the stick-to-it-iveness.

I chose the easier road of following Lothar's hypothesis,
which may be paraphrased as "Call equals() with a null or
cross-classed argument? Never! (What, never?) No, never!
(What ne-e-e-ver?) Well, hardly ever!" Quantifying the
difference between "hardly ever" and "never" is a task beyond
my powers -- although it might be within yours -- so I looked
at the limiting question: In the most optimistic case one
could imagine, where "hardly ever" turned out to be exactly
"never," how much gain could one possibly hope for? That is,
I found an upper bound -- a loose bound, no doubt, but a bound
nonetheless. If you can sharpen it, I encourage you to do so.

--
Eric Sosman
esosman@xxxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: Check if Function Exists
    ... a block would throw an exception without executing this block to begin with. ... The catch block's identifier is then bound to that new object. ... Because such optimization would be unobservable, it could not be shown to be non-complian. ... throw atom; ...
    (comp.lang.javascript)
  • RE: Strange behavior with dynamic code compilation and VS.NET debu
    ... I think someone else suggested that it was optimization related; ... "Mike Miller" wrote: ... > so when I compile with debugging information I get different behavior then ... >> And you'll get the usual exception information when the program aborts. ...
    (microsoft.public.dotnet.framework)
  • Re: Java optimization.
    ... The value of str would have to be known and the semantics of Integer.parseInt would have to be guaranteed to not throw an exception. ... One can argue that the call related to the assignment of the value should be optimized as well, but some assignments for unused variables may be purposeful in effect. ... I can't see how the optimization would avoid violating the JLS in these circumstances without requiring serious in-depth analysis of the code and also keeping binary compatibility. ... The Sun Java compiler does not optimize because optimized code hampers the ability of the JIT optimizer to optimize the code (although variable propagation analysis probably doesn't have an impact). ...
    (comp.lang.java.programmer)
  • Re: Problems with Optimization On
    ... the exception is not thrown ... > selectively turn on and off optimization in the blocks of code using ... Inline explicit control of optimisation to fix a bug is pointless. ... arrays and pointers to local variables. ...
    (alt.comp.lang.borland-delphi)
  • Re: Performance issue (bug?) with .NET 2 ListView
    ... Ok, I see what you are saying, yes, it will delegate to Equals, but ... the first check in the Equals overload is against the length. ... Perhaps an exception is being generated and swallowed. ... private int ConvertToInt ...
    (microsoft.public.dotnet.languages.csharp)