Signs of stupid Java code

[Darryl L. Pierce]

If my understanding of the JVM is correct, a method call has MUCH more
overhead than creating a local int variable. Also consider how
indexOf(char) is probably implemented: by iterating through each
character in the string until a match is found - this means YET ANOTHER
method call for each iteration.

And wouldn't the compiler have to create the variable anyway? After all,
we need SOME place to store the return value.

I'll confess complete ignorance of the JVM's workings. Won't it, when
compiling for optimization, inline some method calls? If so, then the
overhead of a method call is moot.

 

[Darryl L. Pierce]

This is, of course, going to depend on test cases. If you're testing
extremely long strings with the @ close to the end and no dots at all,
then clearly the constant-time substring operation will be overwhelmed
by the linear-time additional search distance. In cases where the dot
lies after the @ (best case for not doing the substring), the version
with substring will be slower by a small constant increase (not even a
constant factor) in execution time.

This also raises questions about importance of efficiency; the advantage
for the substring lies in failure cases, which tend to be comparatively
unimportant with regard to efficiency in many applications. The
advantage for the non-substring code, while being a far smaller
advantage, occurs in the mainline case rather than the failure case.

In other words, there is no "best" answer without more description of
the problem.

Quite right! And, on top of that, the more I thought about this last night
(yes, I spend time pondering Java-related subjects and programming in
general when I should be doing more productive things, like finishing up
_Why People Believe Weird Things_ by Michael Shermer <g>) was that, with a
test of 10M addresses, the one neither algorithm differed from the other by
anything more than a fraction of a second (about 1/2). With that small a
gap in performance between the two, is there any *real* difference between
them? To have to go to the extreme of shoving 10M iterations just to show a
miniscule difference is, IMHO, argumentum ad absurdum...

 

[Jesper Nordenberg]

Yes, it can. I believe it to be no less efficient than creating a substring
and searching that. By searching for the last index, we don't create an
intermediate string to search, which your algorithm does.

String.indexOf() does not create a new substring.

Your code is using the indexOf(String) call, not the indexOf(char). Can you
re-run your tests with that change and do they provide different results?

Sure, tests performed with Suns JVM in Windows 2000:

j2sdk1.4.2_02\bin\javaw.exe:

My alg.: 2224 ms
Your alg. with strings: 3986 ms
Your alg. with chars: 3435 ms


j2sdk1.4.2_02\bin\javaw.exe -server:

My alg.: 1432 ms
Your alg. with strings: 3334 ms
Your alg. with chars: 2133 ms

I reversed the methods (tested my algorithm and then yours) and the numbers
changed, moving closer together, around 2000ms each (VMware w/ 256M and
Blackdown JVM 1.4.2)

Could you test with Suns JVM and not running VMWare?

/Jesper Nordenberg

 

[John C. Bollinger]

Mike Baranczak wrote:




I'll confess complete ignorance of the JVM's workings. Won't it, when
compiling for optimization, inline some method calls? If so, then the
overhead of a method call is moot.

The compiler can only inline method invocations under fairly restrictive
circumstances, lest method dispatch (potentially) fail to invoke the
correct method. I am neither a compiler nor an optimization expert, but
it looks to me like only static or final methods on the same class
containing the method invocation could be candidates for inlining.

That's rather beside the point, however. The compiler does not need to
create a local variable in which to store the result of a method
invocation. Instead, the result goes onto the operand stack in the
stack frame from which the method was invoked, and from there it can be
stored in a variable, used directly (not necessarilly right away), or
dropped.


John Bollinger
(e-mail address removed)

 

[Hylander]

Too inefficient, I would use:

if (address != null) {
int index = address.indexOf('@');
if (index > 0 && address.indexOf('.', index + 1) >= 0) {
...
}
}

I guess there are different levels of programming stupidity (no offense ;-).

Nice disclaimer...no sarcasm.

int a = 0;
if(address !=null
&& -1 != (a=address.indexOf('@')) && -1 != address.indexOf('.',a+1))
{

}

 

[Hylander]

Can you think of examples of Java code that are signs of programmer
stupidity? I'll start:

synchronized (new Object()) {
/* ... */
}

The synchronisation is utterly pointless in this case.

In a JSP, (former VB programmer)
There were about 30 different Strings with queries in them and result set
loops nested 4 layers deep and 5 levels of includes and copy pasted stuff
with lots of these numbered variables.

//*=*=*=*=*=*= Lookup select Data *=*=*=*=*=*=

int myCount = 300;

String Sql100 = "SELECT * from myLookup ";
Sql100 +=where myDataStore.lookup = myLookup.id;";

String varSql101 = "SELECT * from myDataStore where name = 'cox';";

ResultSet rs100 = null;
ResultSet rs101_1 = null;

while(rs100==null && rs100.next())
{
stmt4 = rs101_1.execute(varSql101);
while(rs101_1!=null && rs101_1.next())
{
...
}
}

 

[Darryl L. Pierce]

Could you test with Suns JVM and not running VMWare?

Sure. Windows XP, J2SDK 1.4.2, Pentium 4 2.4GHz, 768MB

My algorithm: 6239ms
Your algorithm: 5858ms

Damn, but that's slow. That's platform *hosting* the VM where the code
executes significantly faster. Sheesh!

 

[Matthew A. Pemrich]

But what does it all mean?

I'm looking at all of these, and all i see is a bunch of
semi-structured character groups. Examples of bad coding don't mean
anything if they aren't explained. Don't just post the code, post an
explaination.

It looks like code to me, because I know what code looks like; but it
doesn't mean more than that, to me. I'm not asking for anything
in-depth. Just a quick overview of what it's supposed to do.

Another thing you could do is post the proper code.

Just the point: If this thread is supposed to be informative, let it
be informative. Otherwise, it's just a long run of inside jokes.

--M.Pemrich

Matthew A. Pemrich

_____________________________________________________________________