I am just wondering (in general, not specific to one language), does having a lot of commented out lines in the code like: #this explains what happens in the line below does that slow the actually program down? I know that the compiler should skip right over it, but doesn't it have a slight impact? thanks eskiled www.linuxteens.com

None whatsoever, not the slightest, zilch, sod all. It might slow the compilation down a little but will have no effect at all on the resulting programme. Stuart

For compiled languages it's like Stuart says. The compiler completely ignores it and none of the comments make it into the machine code. If you're using an interpreted language like Javascript (not Java), WSH, ASP, PHP, etc, then it probably does slow it down a very small amount. The slowdown occurs because there is time taken by the parser to take note of the comment starting character (;, #, //) and depending on the comment type it may check the commented-out characters to see if they are the ending character. This is amazingly minuscule and in the real world nobody will notice, even for a huge program. I suppose if you put a billion or so comment lines in the code then you'll notice a slowdown, but even then it probably wouldn't be as bad as trying to load that file into memory :)

The difference is microseconds, unless we are talking extremes. "If you're using an interpreted language like Javascript (not Java), WSH, ASP, PHP, etc..." Remember, some of these compile and then run (within the context of the interpreter). That means execution time is not affected by comments. The time (including compilation) is further cut down if the compiler scans the source and cuts out comments in the first stage (pre-parsing). Since most of the command set in an interpretated language is already memory resident, there may be no measurable effect at all (given certain conditions).

Remember, some of these compile and then run (within the context of the interpreter). That's true, I didn't think about it. Do you have any ideas how one could find out which languages are compiled before interpretation? Would you say that they compile in the same way or similar to the way Java does, generating a bytecode that is then run inside a virtual machine of sorts, or some other way? The only thing that comes to mind is that often times (but not always, so I'm not sure what the cause is) if you have an error in some of those languages I mentioned they will run fine until they encounter the error. This seems like they wouldn't have been compiled beforehand, right?

okay thats great :) thanks so much! (fyi i am using tcl/tk, a compiled language) eskiled www.linuxteens.com

"Do you have any ideas how one could find out which languages are compiled before interpretation?" Somewhere between the documentation, the O'Reilly book, and the dev mailing list. And of course Google. One example is PHP. "Would you say that they compile in the same way or similar to the way Java does, generating a bytecode that is run inside a virtual machine...?" How a langauge is implemented may or may not cleanly seperate compile time and runtime. An intermediate format, maybe like bytecode, is usually involved. This is not always true, though. Further, not all these languages use an assembler-like code (as in the case of Java bytecode). Some interpreters seperate the execution and interpretation phase into two distinct parts, thereby providing a (theoretically) clean seperation between runtime and compile time. In practice, I'm not sure this is really useful or entirely true. We can say Java's bytecode is seperate, but the VM does a lot of syntax, type, and object checking upon loading (even linking). LISP is a nice, crazy example of how this can be made very confusing. It allows the runtime and compile time code to interact - call a fuction, use a variable, etc. The VM is there, but it is more like a software environment that doubles as a machine environment. So your interpreter can take the liberty of blurring the line between compiler/loader. Regardless, intermediate formats always exist, but are not always intended for use outside internals. "if you have an error in some of those languages I mentioned they will run fine until they encounter the error. This seems like they wouldn't have been compiled beforehand, right?" The code has to be compiled, but there are exceptions to strict compile time and runtime borders (as mentioned above). Depends on the error and enviroment. Don't forget sometimes errors are suppressed until the compilation phase finishes or things get hairy (ex. Perl). In Perl, there is such a thing as a compile phase and run phase. These are basically ways of saying that during compilation, some runtime operations can be performed (only certain ones, of course). Similarly, during the runtime phase, some compile time operations can be done. Still, Perl compiles first and then executes.