OK, I understand. My problem is that I was pretty sure what I was
testing, and then I got a mail that told me I wasn't. Also the mail
made suggestions on how to improve the overall speed of the code, by
removing the crucial commands, which is contradicting the whole idea
of efficiency testing.
I'm happy you've learned something. I think I will admit that I have
too, as soon as I've calmed down a little... ;-)
-Andreas
>Andreas wrote:
>
>>Sorry I got a little upset here, but I think your mail was a little
>>insulting... ;-)
>
>Well, that's too bad. I never meant to be insulting. I hope you'll
>get well again.
>
>As I stated, my letter was not exhaustive. I did not have the time
>to investigate the matter as thoroughly as I wanted, but still I
>felt, that I could add some relevant angle to the debate. I
>certainly think, that it's interesting to see the differences, in
>syntax performance, and during my tests, I was surprised to see
>these differences. When two different syntax constructs of otherwise
>identical operations yields different performance, it must mean,
>that they have compiled to different byteCode. Just stating the
>obvious. Apparently it is quite easy to write dot syntax with
>performance inferior to verbose syntax. This is a very valid point
>of this thread. It may have historical roots, in the pre-dot ages of
>Lingo. Anyway, it is also possible to write dot syntax with
>performance equal to verbose syntax. This was one of my points. And
>thus I think you invite the feedback, when you make a broad stroke
>and say "Is dot syntax slower? Yes. It. Is." That's a definitive
>statement, and it's validity can be questioned.
>
>When answering this kind of statement, I not only answer this
>specific thread. You see, I've also got emotions, and one the things
>that annoys me, is when people make these broad strokes and declares
>this or that a bad thing. Especially when I find their claims
>unwarranted. This is something, that I think happens frequently on
>the lists. Well annoyed as I may be, I'm sure that people don't make
>these claims out of bad will. They have established tests, and they
>try to derive some conclusions, and they raise a relevant debate,
>but they must be prepared, to hear arguments from people with a
>different point of view.
>
>Let me give an example:
>Some time ago, on one of the lingo lists, somebody made some tests,
>that they thought indicated, that behaviors are slow. So they made
>the broad claim "behaviors are slow!".
>Well, it turned out, that what they were actually seeing was, that
>repeatedly evaluating sprite references, and addressing
>scriptInstances through the multiple inheritance mechanism of a
>sprite object was slow.
>It could be showed, that the examples could be just as efficiently
>implemented with behaviors, provided that you used an optimal
>structure. In this case it meant: Evaluate sprite references once;
>establish pointers to the actual scriptInstances on on the sprites,
>aka. the behaviors, and then address these objects directly, rather
>than routing messages through the spriteObject.
>So the claims were _wrong_ (in my view), but they did raise an
>interesting debate, and hopefully it helped some understand
>behaviors better.
>
>Likewise, I have seen examples of people attacking OOP techniques
>out of lack of understanding of the principles, and implementation
>strategies. And as you can guess, this makes me steam.
>
>It appears to be general human thing, that we like to have rigid
>guidelines, that we can lean on. I just feel, that many times, we
>trap ourselves in these guidelines, and fail to be prepared to step
>out of the box.
>
>OK, hopefully now you have the background to understand, that when I write:
>"When you make a test, are you sure what you're really testing?"
>The "you" is not referring to Andreas, but generally to people
>making broad assumptions, and definitive statements.
>And my statement is loaded with my opinion about this kind of
>statements in general. Thus if you take it personally, I understand
>your feeling insulted.
>
>And thank you for showing your examples of syntax speed differences.
>It was an eye-opener, and I already learned something useful.
>
>BTW: I've found that when making string operations, there does not
>seem to be a modern syntax, that is as fast as the almost obsolete
>"put this after that". This is slower: "that = that & this", which
>is the syntax I prefer, when not making performance critical
>operations.
>
>
>===============================
>Cheers, Jakob Hede Madsen.
>email: <mailto:[EMAIL PROTECTED]>
>===============================
>
>
>[To remove yourself from this list, or to change to digest mode, go to
>http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
>email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
>Lingo-L is for learning and helping with programming Lingo. Thanks!]
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
