Re: Perform Thru/Go to vs. Perform - Compile Speed

From: Michael Wojcik (mwojcik_at_newsguy.com)
Date: 04/29/04 

Date: 29 Apr 2004 15:50:59 GMT

In article <4090222C.FDA56581@mb.sympatico.ca>, Peter Lacey <lacey@mb.sympatico.ca> writes:
>
> I don't see why simply changing the code to goto-less would make the program
> compile faster. There would be roughly the same number of statements, I'd
> guess.

I suspect Jeff Lanam is correct - the structured program requires a
lot less graph processing in the compiler. Modern compilers on modern
hardware spend relatively little of their time in lexical analysis
(which is where number of source lines would be most relevant, in
terms of CPU cycles); most of it is in operating on the internal
program representation, which is usually a directed acyclic graph.
(Of course number of source lines will affect memory consumption and
file I/O, which may dominate in some cases.)

Conceptually, a typical compiler analyzes source to tokenize it and
remove stuff the compiler isn't interested in (like comments and
inconsequential whitespace). That's passed to a parser, which builds
an internal representation of the program. In concept that's a tree
(where for example you might have an "ADD" node with child nodes for
the operands), but typically it's actually a directed acyclic graph -
a tree where some branches are attached at more than one place, so
common code elements can be reused.

With spaghetti code, building and refining the DAG can get very
complicated, because there aren't so many neat separations between
areas of the graph. So the compiler has to spend more time wandering
around in the graph figuring out how to best fit things together -
particularly if it's doing any optimization.

Also, a complicated graph representing spaghetti code is likely to
have poor locality of reference: the compiler will jump around in it
rather than mostly working in one section, then in another, and so
on. That means more cache hits and potentially more paging to and
from virtual memory, which can be huge performance killers. 

-- 
Michael Wojcik                  michael.wojcik@microfocus.com
Company Secretary Finance Manager
 1) Half-grey haired executives.
 2) Must be waist-deep in their field of activities.
 3) Must be having the know-how and the do-how of the latest
    developments in their respective fields.
   -- from "Appointments Vacant" section of Business India

Relevant Pages

  • Re: derefrencing pointer to incomplete type
    ... struct _graph_vertex { ... If your compiler complains if you take away ... - you forgot to check for malloc() success or failure. ... typedef struct _graph graph_type; ...
    (comp.lang.c)
  • LMbench as gcc performance regression test?
    ... of LMBench results vs. Linux kernel version, ... same compiler. ... Has anyone seen a similar graph showing LMBench results vs. gcc version, ...
    (Linux-Kernel)
  • Re: LMbench as gcc performance regression test?
    ... >>of LMBench results vs. Linux kernel version, ... >>Has anyone seen a similar graph showing LMBench results vs. gcc version, ... I need to make sure that moving to a newer compiler for our kernel ...
    (Linux-Kernel)
  • Re: Code analysis, call graphs for Common Lisp
    ... This will produce a call graph, ... > since it's in the compiler it should handle macros and such just fine. ... I suppose turning off the compiler optimisations might ... David Trudgett ...
    (comp.lang.lisp)
  • Re: stack overflow at compile time
    ... label each arc with the stack size of the routine ... compiler that sees the whole program, ... overlap properly on the call graph. ...
    (comp.compilers)