Constants slow things down

snoofle

I was asked to help someone on another team decipher their central business-logic module so that it could be changed. It looked something like this:

[code]
if ( (status==1 && CustomerCode=='A' && OrderType == null) ||
(status==1 && CustomerCode=='B' && "ABC".equals(OrderType)) ||
(status==1 && CustomerCode=='C' && "DEF".equals(OrderType)) ||
(status==1 && CustomerCode=='D' && "GHI".equals(OrderType)) ||
(status==1 && CustomerCode=='E' && "JKL".equals(OrderType)) ||
(status==2 && ...)
snip approximately 350 lines
) {
triggerMainProcdHere();
}

In fairness, the routine does accurately and efficiently check a lengthy series of business rules, but the constants are not exactly helpful to the uninitiated...

When we tracked down the original developer and asked him why he didn't use enum's or at least static constants with useful names, he explained: "It takes time to process long names and this routine needs to be efficient". When we told him that the extra compile time would be milliseconds, he explained that "Java is an interpreted language, and so the constant names would need to be processed each time the statement was interpreted". Um, wha...?

It took two weeks, but we tracked down the meaning of every single constant. The routine was changed to something along the lines of:

if ( (status==ValidOrder && (CustomerCode==Individual && OrderType == null) ||
CustomerCode==Corporation && Filled.equals(OrderType)) ||
CustomerCode==Religious && PartiallyFilled.equals(OrderType)) ||
CustomerCode==Political && Shipped.equals(OrderType)) ||
CustomerCode==Educational && AwaitingPayment.equals(OrderType))) ||
(status == IncompleteOrder && ...)
snip approximately 350 lines
) {
triggerMainProcdHere();
}

From that point, the changes were easy...
[/code]

snoofle

Ok, forget the post - WTF is up with this forum and formatting?

PJH

@snoofle said:

I was asked to help someone on another team decipher their central business-logic module so that it could be changed. It looked something like this: <font face="Lucida Console" size="2"> if ( (status==1 && CustomerCode=='A' && OrderType == null) || (status==1 && CustomerCode=='B' && "ABC".equals(OrderType)) || (status==1 && CustomerCode=='C' && "DEF".equals(OrderType)) || (status==1 && CustomerCode=='D' && "GHI".equals(OrderType)) || (status==1 && CustomerCode=='E' && "JKL".equals(OrderType)) || (status==2 && ...) snip approximately 350 lines ) { triggerMainProcdHere(); }
In fairness, the routine does accurately and efficiently check a lengthy series of business rules, but the constants are not exactly helpful to the uninitiated...

When we tracked down the original developer and asked him why he didn't use enum's or at least static constants with useful names, he explained: "It takes time to process long names and this routine needs to be efficient". When we told him that the extra compile time would be milliseconds, he explained that "Java is an interpreted language, and so the constant names would need to be processed each time the statement was interpreted". Um, wha...?

It took two weeks, but we tracked down the meaning of every single constant. The routine was changed to something along the lines of:

if ( (status==ValidOrder && (CustomerCode==Individual && OrderType == null) ||
CustomerCode==Corporation && Filled.equals(OrderType)) ||
CustomerCode==Religious && PartiallyFilled.equals(OrderType)) ||
CustomerCode==Political && Shipped.equals(OrderType)) ||
CustomerCode==Educational && AwaitingPayment.equals(OrderType))) ||
(status == IncompleteOrder && ...)
snip approximately 350 lines
) {
triggerMainProcdHere();
}

From that point, the changes were easy...
</font>

Have you considered using Markdown?

snoofle

When I entered the post, I didn't get the formatting bar, so of course, everything is strung together as one long sentence. *Now* I get the formatting bar... sheesh. Let's try again:

I was asked to help someone on another team decipher their central business-logic module so that it could be changed. It looked something like this:

if ( (status==1 && CustomerCode=='A' && OrderType == null) || 
     (status==1 && CustomerCode=='B' && "ABC".equals(OrderType)) ||
     (status==1 && CustomerCode=='C' && "DEF".equals(OrderType)) ||
     (status==1 && CustomerCode=='D' && "GHI".equals(OrderType)) ||
     (status==1 && CustomerCode=='E' && "JKL".equals(OrderType)) ||
     (status==2 && ...) 
     snip approximately 350 lines 
   ) { 
     triggerMainProcdHere(); 
}

In fairness, the routine does accurately and efficiently check a lengthy series of business rules, but the constants are not exactly helpful to the uninitiated... When we tracked down the original developer and asked him why he didn't use enum's or at least static constants with useful names, he explained: "It takes time to process long names and this routine needs to be efficient". When we told him that the extra compile time would be milliseconds, he explained that "Java is an interpreted language, and so the constant names would need to be processed each time the statement was interpreted". Um, wha...? It took two weeks, but we tracked down the meaning of every single constant. The routine was changed to something along the lines of:

if ( (status==ValidOrder && (CustomerCode==Individual && OrderType == null) || 
                                     CustomerCode==Corporation && Filled.equals(OrderType)) || 
                                     CustomerCode==Religious && PartiallyFilled.equals(OrderType)) || 
                                     CustomerCode==Political && Shipped.equals(OrderType)) || 
                                     CustomerCode==Educational && AwaitingPayment.equals(OrderType))) ||
     (status == IncompleteOrder && ...) 
     snip approximately 350 lines 
   ) { 
     triggerMainProcdHere(); 
}

From that point, the changes were easy...

Lingerance

@snoofle said:

I was asked to help someone on another team decipher their central business-logic module so that it could be changed. It looked something like this:
if ( (status==1 && CustomerCode=='A' && OrderType == null) ||
     (status==1 && CustomerCode=='B' && "ABC".equals(OrderType)) ||
     (status==1 && CustomerCode=='C' && "DEF".equals(OrderType)) ||
     (status==1 && CustomerCode=='D' && "GHI".equals(OrderType)) ||
     (status==1 && CustomerCode=='E' && "JKL".equals(OrderType)) ||
     (status==2 && ...)
     snip approximately 350 lines
   ) { 
   triggerMainProcdHere(); 
}
In fairness, the routine does accurately and efficiently check a lengthy series of business rules, but the constants are not exactly helpful to the uninitiated...

When we tracked down the original developer and asked him why he didn't use enum's or at least static constants with useful names, he explained: "It takes time to process long names and this routine needs to be efficient". When we told him that the extra compile time would be milliseconds, he explained that "Java is an interpreted language, and so the constant names would need to be processed each time the statement was interpreted". Um, wha...?

It took two weeks, but we tracked down the meaning of every single constant. The routine was changed to something along the lines of:
if ( (status==ValidOrder && (CustomerCode==Individual     && OrderType == null) ||
                                        CustomerCode==Corporation  && Filled.equals(OrderType)) ||
                                        CustomerCode==Religious      && PartiallyFilled.equals(OrderType)) ||
                                        CustomerCode==Political        && Shipped.equals(OrderType)) ||
                                        CustomerCode==Educational  && AwaitingPayment.equals(OrderType))) ||
     (status == IncompleteOrder && ...)
     snip approximately 350 lines
   ) { 
   triggerMainProcdHere(); 
}
From that point, the changes were easy...

Fixed

Outlaw_Programmer

^^^ What did you fix, anyway? I've read your post like 3 times and I still can't find it...

Anyway, even though Java may be "interpreted" sometimes, I'm pretty sure constants get special treatment and are inlined at compile time instead of having to be looked up every time they are referenced...

seaturnip

Of course, even in languages that actually directly interpret the source, the overhead of looking up constants in a hashtable is unlikely to have any visible impact on performance. Premature optimization squared is evil...

snoofle

I replaced al the literal constants with Named constants spelling out what they mean

Lingerance

@Outlaw Programmer said:

^^^ What did you fix, anyway? I've read your post like 3 times and I still can't find it...

I presume you're referring to my post, compare my quoted text to the OP, also note that his correction and mine have the same timestamp in case you're wondering why both of us corrected the issue.

shadowman

@snoofle said:

When I entered the post, I didn't get the formatting bar, so of course, everything is strung together as one long sentence. *Now* I get the formatting bar... sheesh. Let's try again:

Yeah, I get that problem too, since the last update. Sometimes the formatting editor doesn't appear at all, and sometimes it takes it a while to load, in firefox 2. I'm sure we'll take the usual route and just blame it on the extensions.

Noam_Samuel

Ctrl+A Backspace

snoofle

Ctrl-A Backspace - doesn't seem to do anything if the formatting bar doesn't display...

mrprogguy

What the Java runtime interprets is bytecode, not actual Java code. The literals, constants, and variables are in the bytecode as references or literal inlines (for constant values), so there's no time spent "interpreting" the names as the applet runs.

Of course, the real WTF is that code in the first place. Multi-line if testing usually means you don't have a clear view of the problem at hand.

@mrprogguy said:

What the Java runtime interprets is bytecode, not actual Java code. The literals, constants, and variables are in the bytecode as references or literal inlines (for constant values), so there's no time spent "interpreting" the names as the applet runs.

Of course, the real WTF is that code in the first place. Multi-line if testing usually means you don't have a clear view of the problem at hand.

Winner.

Constants are converted to literals during the initial IL compiling pass. Go donkey punch the original developer.

Additionally, judging by the code sample, I'm going to go out on a limb and venture that the original developer has no idea how to properly design an object oriented business objects layer.

Morbii

@Jonathan Holland said:

@mrprogguy said:

What the Java runtime interprets is bytecode, not actual Java code. The literals, constants, and variables are in the bytecode as references or literal inlines (for constant values), so there's no time spent "interpreting" the names as the applet runs. Of course, the real WTF is that code in the first place. Multi-line if testing usually means you don't have a clear view of the problem at hand.

Winner.

Constants are converted to literals during the initial IL compiling pass. Go donkey punch the original developer.

Additionally, judging by the code sample, I'm going to go out on a limb and venture that the original developer has no idea how to properly design an object oriented business objects layer.

Strange, I didn't think anyone was actually looking for an explanation. I beleive the OP was saying the previous guy was a dolt, in so many words.

MasterPlanSoftware

@Morbii said:

@Jonathan Holland said:
@mrprogguy said:

What the Java runtime interprets is bytecode, not actual Java code. The literals, constants, and variables are in the bytecode as references or literal inlines (for constant values), so there's no time spent "interpreting" the names as the applet runs. Of course, the real WTF is that code in the first place. Multi-line if testing usually means you don't have a clear view of the problem at hand.

Winner.

Constants are converted to literals during the initial IL compiling pass. Go donkey punch the original developer.

Additionally, judging by the code sample, I'm going to go out on a limb and venture that the original developer has no idea how to properly design an object oriented business objects layer.

Strange, I didn't think anyone was actually looking for an explanation. I beleive the OP was saying the previous guy was a dolt, in so many words.

I agree. TRWTF is people feeling compelled to explain how Java works.