Well, last night before I went to sleep I was programming the majority of that day working on a program that would:

A: Record the users screen every 21 - 33.3 milliseconds.B: After recording, store the captured frames, than start a GUI that will shuffle through the pictures giving a feeling of smooth motion. (play/pause buttons etc)

My problem while programming is that half the time while I'm programming a project, after I've turned it into something nice/useable, I've as some might call it 'hard-coded' it, figured out where it starts/stops etc programmed the program to run smoothly if that makes sense o.O.

Here is my question: Why is example 2 taking 3 seconds+ to complete 1 loop, where in example 1 it executes 1 loop in about 0-16ms?The only difference between the two examples, it that example 2 calls 'System.out.println' before starting the loop.

Hope somebody has some feedback/input, going to be depending on consistency ^__^.EDIT: I never knew this, I removed the Integer variable 'loops' out of the Constructor, and added it's decleration in the main class as a variable instead, just by doing that it caused the interval rate of which the loop performs at to hop from 0-16ms to 152-172ms?Nothing's different, just where the variable was declared D:

I never knew this, I removed the Integer variable 'loops' out of the Constructor, and added it's decleration in the main class as a variable instead, just by doing that it caused the interval rate of which the loop performs at to hop from 0-16ms to 152-172ms?Nothing's different, just where the variable was declared D:

That is easily explained. Local variables cannot be seen from anywhere other than the function you are currently in, so there is no need to make sure changes are visible to other code. Local variables can be stored on the stack or in a CPU register. Register reads/writes are as fast as you can get. Field variables may need to be written to RAM, meaning

loops++

would read and write a value every time it was executed. A register could be incremented in one CPU instruction and with no memory delays for reading or writing, since the data is already at hand and the computer knows nothing else changed its value.

Lol, no .That is a snippet from Launcher.java (Simply some variables and the constructor displayed above in the examples).

This doesn't have too much to do with my 'Java Screen Recorder / Player'.I only wrote that code in the examples above this morning so that I could debug a 'while(condition == true)' loop, and see when it ended etc, and in the process of doing that i discovered the 'opening post' issue.

That is easily explained. Local variables cannot be seen from anywhere other than the function you are currently in, so there is no need to make sure changes are visible to other code. Local variables can be stored on the stack or in a CPU register. Register reads/writes are as fast as you can get. Field variables may need to be written to RAM, meaning

loops++

would read and write a value every time it was executed. A register could be incremented in one CPU instruction and with no memory delays for reading or writing, since the data is already at hand and the computer knows nothing else changed its value.

That's badass lol.So I haven't been the optimizer I thought I was. Thanks mate, noted.

Both do the same amount of work, but the loop does it less efficiently. The compiler notices it and replaces the original code with more efficient code. It does not automatically recognize every possible improvement and might take a long time if it could, so it might pass over certain blocks of code and assumes the programmers were smart enough to figure it out themselves. A just in time (JIT) compiler may make optimizations on the fly, so its possible that if you called that function a few more times and the compiler decided it was worth the investment to try improving that code even if it did not do so ahead of time (AOT). Three times is a magic number in Hotspot, so both versions might run in 0ms if you tested it enough times in the same run, but you should not rely on optimization of any form for changing the structure of your program.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org