Jürgen Hestermann wrote:
I disagree with any statement saying that for .. in loop is
only a type-saver. It's a good language extension and should be included
(since Delphi already have this, it will also be a good idea).
Consider the
following example:
for d in [Monday,Wednesday,Friday] do ;
// versus
for d:=Low(TDaySet) to High(TDaySet) do
if d in [Monday,Wednesday,Friday] then ;
The latter one has iteration overheads, while the former can be
optimized to
loop as many as needed. I'm not saying I'm the best Pascal programmer,
but
in case there's a (better) solution to this (rather than extending the
language) please tell me.
I think there will be no performance difference because internaly the
compiler has to generate something like the first for-loop anyway.
No. It could unroll the loop, and then use constants throughout the
three copied loop-bodies instead. Of course, a smart compiler could end
up with the same approach after analyzing the code, so indeed: There
should be no performance difference.
It
will only be hidden from the programmer and I am not sure whether this a
good thing.
Everything that obscures what's going on under the hood has the
potential to generate performance problems.
Yes, that's what I hear from C-enthusiasts all the time. And that's also
why everything should be written in assembler these days, because then
performance problems would jump right at you when reading the code.
(In case anyone wonders, yes, the last sentence above is 100% sarcasm.)
> In your example, you may not
be aware that at the end all possible members have to be checked for
beeing part of the set. If you only read
for d in [Monday,Wednesday,Friday] do ;
you may think that the loop is run through only 3 times, but internally
there are much more iterations (to check the "if d in
[Monday,Wednesday,Friday]").
Indeed. But there could even be no loop at all, even if there's a loop
expression in the source code.
Vinzent.
P.S. Honestly, Pascal (and especially ObjectPascal) already hides quite
some stuff from the programmer. Properties, for example, can hide
potentially costly procedure calls in simple assignment statements.
Things like
SomeStringList['Name'] := 'Value';
might be a relatively cheap O(1) operation if implemented with a hash
table, it could be an O(log n) operation if the list is sorted and a
binary search is done, or it could even be a O(n) operation if
implemented by a simple linear search, but who knows? Some of the time
you don't even care, because the number of strings is not large enough
to make a noticeably difference; in fact, the usage of AnsiStrings alone
and the associated reference counting and constant memory allocation and
deallocation might even be much more influencing on the overall performance.
Don't get me wrong, usually this hiding of implementation details is a
good thing, because it let's you solve the problem at hand a lot more
quicker. If the solution turns out to be "not fast enough", you can
still start optimizing instead of doing it the other way around.
Mantra: First make it work, then make it fast.
IOW: A fast, but wrong solution is one thing first: Wrong. No matter how
fast it does it wrong.
BTW, any performance differences in the example above highly depends on
the work done in the loop body anyway, so whining about possible
performance issues is quite a bit premature here. ;)
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
