OT how often is writing machine-faster code really a consideration?

[Art Kendall]

Except for a few exceptions such as not putting in too many EXECUTEs, how often do users find that it even makes a perceptible time difference to worry about faster code?

A rhetorical question is: "What is the relative value of machine time vs personnel time to re-draft, QA review, update, etc?"

Another rhetorical question is: "What is the relative value of fewer keystrokes in a first draft vs personnel time to re-draft, QA review, update, etc?"

[John F Hall]

Art

 

Well said.  However, "Personnel time" is one consideration: mine is "Personal time".  This thread is beginning to look a bit like a debate about angels dancing on the heads of pins. 

 

John

 

John F Hall (Mr)

[Retired academic survey researcher]

 

Email:   [hidden email] 

Website: www.surveyresearch.weebly.com

SPSS start page:  www.surveyresearch.weebly.com/1-survey-analysis-workshop

 

 

 

-----Original Message-----
From: SPSSX(r) Discussion [mailto:[hidden email]] On Behalf Of Art Kendall
Sent: 19 April 2015 16:12
To: [hidden email]
Subject: OT how often is writing machine-faster code really a consideration?

 

Except for a few exceptions such as not putting in too many EXECUTEs, how often do users find that it even makes a perceptible time difference to worry about faster code?

 

A rhetorical question is: "What is the relative value of machine time vs personnel time to re-draft, QA review, update, etc?"

 

Another rhetorical question is: "What is the relative value of fewer keystrokes in a first draft vs personnel time to re-draft, QA review, update, etc?"

 

 

 

 

 

-----

Art Kendall

Social Research Consultants

--

View this message in context: http://spssx-discussion.1045642.n5.nabble.com/OT-how-often-is-writing-machine-faster-code-really-a-consideration-tp5729264.html

Sent from the SPSSX Discussion mailing list archive at Nabble.com.

 

=====================

To manage your subscription to SPSSX-L, send a message to [hidden email] (not to SPSSX-L), with no body text except the command. To leave the list, send the command SIGNOFF SPSSX-L For a list of commands to manage subscriptions, send the command INFO REFCARD

===================== To manage your subscription to SPSSX-L, send a message to [hidden email] (not to SPSSX-L), with no body text except the command. To leave the list, send the command SIGNOFF SPSSX-L For a list of commands to manage subscriptions, send the command INFO REFCARD

[Richard Ristow]

At 10:12 AM 4/19/2015, Art Kendall wrote:

>Except for a few exceptions such as not putting in too many EXECUTEs, how
>often do users find that it even makes a perceptible time difference to
>worry about faster code?

It's rare, but I've seen a few bad efficiency mistakes in SPSS. One
that comes to mind was breaking up a large file into 100 subfiles by
logic that required the original file to be passed, in its entirety,
each time. Another that's come up is recoding a variable with a chain
of IF statements -- one of the few easy ways to make an SPSS job
badly CPU-bound.  (Changing to RECODE can give an order of magnitude
speed improvement, as well as much better readability and maintainability.)

>A rhetorical question is: "What is the relative value of machine time vs
>personnel time to re-draft, QA review, update, etc?"

The non-rhetorical answer is, in most programming environments there
are ways to make big mistakes, and the time to avoid them is worth
it. In most cases, that gives code as readable, or more readable,
than with the big mistakes left in.  Part of being a good programmer
is being aware of the pitfalls.

But otherwise, it's generally best to look for a clean,
comprehensible design, and not worry about odds-and-ends of
optimization.  As has famously been said,

"More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason -
including blind stupidity. --W.A. Wulf, from "A Case Against the
GOTO," Proceedings of the 25th National ACM Conference, August 1972,
pp. 791-97 (as quoted and cited at http://en.wikiquote.org/wiki/William_Wulf).

>Another rhetorical question is: "What is the relative value of fewer
>keystrokes in a first draft vs personnel time to re-draft, QA
>review, update, etc?"

Maybe I'm the wrong person to respond here -- my code may be the
least terse of any regular list poster's.  But I think of keystrokes
as very cheap indeed;  the time it takes to eliminate strokes is
usually more than the time to type them.  Most particularly, I never
abbreviate keywords, and split lines very freely to have their
typographical structure clarify their logical structure.

By the by, scratch variables are an invaluable tool in SPSS, for
breaking up complex expressions into clear parts without permanently
cluttering the name space with intermediate values. Like this,
converting time to AM/PM form, using scratch variables to make clear
what constant  time values are being used:

DO IF   $CASENUM EQ 1.
.  COMPUTE #1hr   = TIME.HMS( 1,0,0).
.  COMPUTE #11hrs = TIME.HMS(11,0,0).
.  COMPUTE #12hrs = TIME.HMS(12,0,0).
.  COMPUTE #13hrs = TIME.HMS(13,0,0).
END IF.

DO IF   Time LT  #1hr.
.  COMPUTE AmPm    = 'AM'.
.  COMPUTE Time12  = Time + #12hrs.
ELSE IF Time LT  #12hrs.
.  COMPUTE AmPm    = 'AM'.
.  COMPUTE Time12  = Time.
ELSE IF Time LT  #13hrs.
.  COMPUTE AmPm    = 'PM'.
.  COMPUTE Time12  = Time.
ELSE.
.  COMPUTE AmPm    = 'PM'.
.  COMPUTE Time12  = Time - #12hrS.
END IF.

On the other hand, you *could* minimize keystrokes and let clarity go
to the winds:

COMPUTE AmPm   = SUBSTR("AMPM",1+2*(Time GE TIME.HMS(12)),2).
COMPUTE Time12 = TIME.HMS(1)  + MOD(Time+TIME.HMS(11),TIME.HMS(12)).

=====================
To manage your subscription to SPSSX-L, send a message to
[hidden email] (not to SPSSX-L), with no body text except the
command. To leave the list, send the command
SIGNOFF SPSSX-L
For a list of commands to manage subscriptions, send the command
INFO REFCARD

[Art Kendall]

great ideas.

wrt line splits I have often advocated vertical alignment of text for syntax and a fixed pitch font helps with that
e.g., (approximating fixed pitch font. this does not split a statement but shows what I mean by vertical alignment)
DO IF $CASENUM EQ 1.
. COMPUTE #1hr     = TIME.HMS( 1,0,0).
. COMPUTE #11hrs = TIME.HMS(11,0,0).
. COMPUTE #12hrs = TIME.HMS(12,0,0).
. COMPUTE #13hrs = TIME.HMS(13,0,0).
END IF.

rather than this
DO IF $CASENUM EQ 1.
. COMPUTE #1hr = TIME.HMS( 1,0,0).
. COMPUTE #11hrs = TIME.HMS(11,0,0).

remember how in grammar school "parallel structure" was emphasized?