No bounds checking for dynamic arrays at compile time?

[H. S. Teoh]

On Thu, Dec 13, 2012 at 05:31:05PM +0100, Chris Cain wrote:
> On Thursday, 13 December 2012 at 09:38:18 UTC, bearophile wrote:
[...]
> >Right, but there are several cases where a little smarter compiler
> >is able to see at compile-time that something bad is present in
> >the code.
> 
> The problem is that it can't solve anything but the most basic of
> errors in code. This type of analysis will simultaneously be
> computationally expensive and useless in _real_ code. My point is
> that, ultimately, run time problems have to be dealt with at run
> time.
> 
> I wouldn't mind this suggestion except for the fact that it will take
> away human resources from much more useful endeavors (not to mention
> increasing compilation time). Many suggestions I see the value in...
> but I see almost none here (as I explained, it won't do anything in
> non-trivial code that you might actually see using dynamic arrays).

Yeah, I think this is a case of premature optimization, a very tempting
trap to fall into for efficiency-minded people (like myself). Many of
these "optimizations" actually hurt, rather than help. Like you said,
making the compiler detect dynamic array length at compile-time is
non-trivial -- in fact, it amounts to solving the Halting Problem, which
is unsolvable -- so the only practical cases that can be done are
trivial and most likely nowhere near the performance bottleneck that
makes optimization necessary in the first place. Definitely not worth
the significant increase in compilation times.

I used to be a big fan of optimizing everywhere, until one day I
actually took the time to profile my code, and discovered to my great
surprise that my hotspots were NOT where I thought they were. They were
all the places where I didn't even think to look because they were so
trivial and so obviously already "optimal". Which meant that 90% of my
"optimization" efforts had been wasted on code that wasn't even
important to optimize, while neglecting the real hotspots.  (In fact,
some of my "optimizations" turned out to actually degrade performance,
because I eschewed a certain implementation technique as "slow" where it
would have helped with the actual hotspots in the code. Not to mention
wasting much of my time in thinking up clever ways of "optimizing",
where a straightforward implementation would have sufficed.) I wouldn't
be surprised if many (most?) programmers will be shocked to learn where
the real hotspots in their code are, contrary to whatever preconceived
notions they may have had.


T

-- 
A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth