Timing loop



  • Yesterday I was asked to review some code for a mid-level developer on another team. I found the following:

       // This thread finishes much more quickly than the thread doing xxx.
       // We periodically put in a loop to slow this thread down as follows
       for (int i=1; i<=1000000; i++) { i=i+1; i=i-1; }

    ... and it was repeated in numerous places in numerous files that comprised the thread's logic! 

    • WTF 1: Thread.sleep
    • WTF 2: Thread.join
    • WTF 3: synchronize 

    Forgive me, but didn't people learn that lesson when PC's got so fast that the timing loops finished in microseconds?

    Mind you, this is not some 20 year old application still in service; it was written in the last month, in Java, by so-called professional Java developers.

    Sheesh

    </rant>



  • WTF4: That code should probably execute pretty much instantaneously.  I assume that the code in the brackets was an attempt to prevent it from being optimized out by the compiler or interpreter, but who knows if that will actually happen.



  • Wow. I'll admit that I did stuff like that a LONG time ago, on the TI-89 calculator, in C, where there was no sleep() function.

    Today, any compiler worth it's salt will immediately recognize such a loop that doesn't modify any memory outside of what's created in that block and cut it out altogether.
     


  • Discourse touched me in a no-no place

    WTF 4: Crap attempt at stopping the compiler optimising the loop out of existence.

    WTF 5: Was the 1e6 hard coded? What happens on the next generation of faster processors (ignoring WTF 4 of course.)



  • I miss QBASIC's good old SOUND 32767,18.2.



  • I have worked with someone like the author of that loop. Someone who never improves his skill set, ever. What he learned in 8-bit BASIC 25 years ago has worked for him, by golly, and he's going to keep doing it until he retires. It's made all the more frustrating in that you're sure he's smart enough to learn, but he has put up a shield against all incoming knowledge and professional skill expansion.



  • @VGR said:

    I have worked with someone like the author of that loop. Someone who never improves his skill set, ever. What he learned in 8-bit BASIC 25 years ago has worked for him, by golly, and he's going to keep doing it until he retires. It's made all the more frustrating in that you're sure he's smart enough to learn, but he has put up a shield against all incoming knowledge and professional skill expansion.

     

    Oh man, I found in some code 2 functions exchanging large amount of text through files. No joke - the lady figured out that concatenating strings in C# was slower than using a file and "optimized the code"... And it was slow because she did thousands of myString += something; instead of using StringBuilder so yes, files don't allocate new memory on each concatenation nor copy the entire data over and over again... oh and they are buffered... but you know - who needs a StringBuilder when a temporary file will do just fine?!



  • Ha...I remember doing something like that back in a first year "Visual Basic" course.  In my defense, I knew it was an awful solution and even commented as such.  I just couldn't get a proper solution working for some reason and the due date was approaching too fast.  I think I still got an A+ on that assignment (which doesn't say much about the teacher, who was over her head teaching that class to begin with). 

     

    I can't imagine coming across something like that in production code...unbelievable. 



  • @nsimeonov said:

    Oh man, I found in some code 2 functions exchanging large amount of text through files.

    Curiously enough, this is the correct method for working with large strings in Bourne shell. 



  • @asuffield said:

    @nsimeonov said:

    Oh man, I found in some code 2 functions exchanging large amount of text through files.

    Curiously enough, this is the correct method for working with large strings in Bourne shell. 

    This presupposes that there is anycorrect method for working with large strings in Bourne shell.



  • @nsimeonov said:

    Oh man, I found in some code 2 functions exchanging large amount of text through files. No joke - the lady figured out that concatenating strings in C# was slower than using a file and "optimized the code"... And it was slow because she did thousands of myString += something; instead of using StringBuilder so yes, files don't allocate new memory on each concatenation nor copy the entire data over and over again... oh and they are buffered... but you know - who needs a StringBuilder when a temporary file will do just fine?!

    I feel your pain. I had to write software that interfaced with another contracted company's software. Their library only worked as a separate executable, and all communication was done with text files. The format of said files was undocumented, to add icing to the cake. I put together a BNF based on my understanding of the format, and I showed it to them and asked if they felt it was accurate. I never got an answer, because they had never seen a BNF before. (I would have thought BNFs to be pretty readable even if you've never seen one, but on that day I was proven wrong.)



  • @nsimeonov said:

    Oh man, I found in some code 2 functions exchanging large amount of text through files.

    Heh, at least she wasn't using the clipboard



  • @JamesKilton said:

    Wow. I'll admit that I did stuff like that a LONG time ago, on the TI-89 calculator, in C, where there was no sleep() function.


    Yeah, but TI-89s (well, most hardware versions) have a set clock speed, so you can be sure that the loop will have the same delay on all calculators it will run on. A PC is different, faster PCs will complete the loop quicker.



  • @Daniel15 said:

    Yeah, but TI-89s (well, most hardware versions) have a set clock speed, so you can be sure that the loop will have the same delay on all calculators it will run on. A PC is different, faster PCs will complete the loop quicker.
    You can't be sure about the loop speed even on the same PC thanks to wonders of power management.



  • @ender said:

    @Daniel15 said:
    Yeah, but TI-89s (well, most hardware versions) have a set clock speed, so you can be sure that the loop will have the same delay on all calculators it will run on. A PC is different, faster PCs will complete the loop quicker.
    You can't be sure about the loop speed even on the same PC thanks to wonders of power management.
    ... and also the joys of pre-emptive multitasking...


Log in to reply