Code comments and execution time

[Michael Morris]

This entire discussion has gone off course because PHP is NOT an interpreted language - it is a compiled language.

It isn't comiled just once though with all subsequent accesses using the compiled version. It is compiled every time someone accesses the web page and the compiled version is run just for that one access and is then discarded with the script being compiled all over again when the page is next referenced.

This is known as a Just in Time compile process (or JIT).

While everything Felgal says here is true - I still would consider PHP a hybrid. In my opinion, any language which has run time evaluation -- an eval() statement -- is almost certainly interpreted and can be called an 'interpreted' language because for all practical purposes it is.

Also, while simple parse errors are caught at the compile pass - symbol table mismatches, such as calls to non-existent functions aren't caught until the line tries to actually execute. In this manner PHP behaves more like an interpreted language than a compiled one. Java after all also uses JIT compiling from the bytecode to the final executable, but it catches many errors at compile time PHP does not. Java also does not have any eval capacity.

Finally, as far as optimization goes, if APC cache or similar mechanism is present PHP can hold the bytecode between page requests and that code can persist for the lifetime of the cache, which has enormous returns in execution speed.

[TomB]

Crimson, Notepad++, the M$ one for .net, gEdit... Of course since acid trip is one of the first things I turn off...

So a few text editors? Not even real IDEs? Helpful.

I do, that's why I'm rabid about hitting enter, tab, or shift-tab, or letting the auto-deindent do it's job.

And when the start tag is more than a screen's height above the end tag? When you have multiple tags at the same level? Tag matching is useful I don't see how you're arguing that it's bad??

Which just gets in the way when it's in two separate functions, or two separate files... and practice the 76 column rule for code but not content.

Don't get me started on arbitrarily imposed "rules"...

No, but I do practice decade old tried and true methods for preventing me from making the simpler mistakes in the first place...

So you still make them. Wouldn't it be better to detect them more easily?

No offense, but spoken like someone not only over-reliant on their tools, but vomiting up code any old way. Lemme guess, classes on H1's, style tags in the markup for static values like width:auto; vague/meaningless three letter classnames and presentational classes like "right"? PRobably have some nice pointless IE conditionals on a layout that shouldn't even need real hacks to work properly all the way back to IE 5.x?

Wow where did that come from? Now I know you're just trolling. Nobody who actually wants a discussion jumps around topics this much, surely?

So... been programming all of six months to a year and never taken a single course or read a book on the subject? Or are the fundementals of elementary programming practices just not taught anymore?

Assumptions, very wrong too. I'm not going to list my academic qualifications because I refuse to be dragged into a pointless "mine is bigger" competition and stoop to your level of arrogance. However, feel free to read some of my posts in the PHP Application Design forum to get a feel for my knowledge in the subject. And as I recently said in another topic, experience on it's own lends no weight to the validity of someone's argument.

I was inferring that it was utterly meaningless in the context of the discussion especially as you were somehow trying to use it to back up a previous point. Why bring up indent styles when a) it's down to personal preference and B) it's completley irrelevant to the discussion at hand?


I'm 95% sure you can't be serious and are just here for the sake of being argumentative.

[deathshadow60]

Wow where did that come from?

r.je - Tom Butler on programming

I've seen far, far worse, but if the markup is that full of bad coding practices, not sure I want to see the PHP behind it.

I'm 95% sure you can't be serious and are just here for the sake of being argumentative.

Deadly serious. It's why I'm pretty much through "working with others" on projects as I can't put up with the "who cares" attitude of most up and coming developers.

[TomB]

r.je - Tom Butler on programming

I've seen far, far worse, but if the markup is that full of bad coding practices, not sure I want to see the PHP behind it.

Tu quoque.

Deadly serious. It's why I'm pretty much through "working with others" on projects as I can't put up with the "who cares" attitude of most up and coming developers.

I can see why people don't like working with you.

[felgall]

While everything Felgal says here is true - I still would consider PHP a hybrid.

This thread is discussing comments. Regardless of what the compile step outputs for PHP the comments will have already been stripped out. The overhead of having the comments only impacts on that compile step - what happens to it after that is the same as if the comments were not there at all.

This is totally different from a purely interpreted language where the comments need to be skipped over every time you get to one.

I agree that PHP is a hybrid but in so far as comments are concerned it behaves close to how compiled programs and nothing like interpreted ones.

[deathshadow60]

This thread is discussing comments. Regardless of what the compile step outputs for PHP the comments will have already been stripped out. The overhead of having the comments only impacts on that compile step - what happens to it after that is the same as if the comments were not there at all.

Except that on first-run or if you aren't running a caching accelerator that byte-code compile step happens whenever you call it. What you called the JIT still has to deal with it, even if the bytecode interpreter does not.

... and compilation is one of the slowest operations there is on a computer since its' basically a lexical parser; even though bytecode is nowhere near as bad as an ACTUAL compiler, especially if we were to talk a multi-target one. See why APM and it's kin offer such miraculous speedups -- they allow you to skip the plaintext to bytecode step IF the program is still in the cache.

This is totally different from a purely interpreted language where the comments need to be skipped over every time you get to one.

Which is why GW-B 4 was faster than 2.x -- comments were stored outside the byte-code and interpolated in realtime by the editor and list functions -- IF they were on their own line. NOT that 4 was around long enough to matter since quickBasic (an ACTUAL compiler) was released at almost the exact same time.

I agree that PHP is a hybrid but in so far as comments are concerned it behaves close to how compiled programs and nothing like interpreted ones.

Which I can agree to IF you are running a caching program like APC and IF have already run the code once and IF it's still in your cache and hasn't been flushed by something else... That's a lot of IF, and if none of those are true and it works as how you said in your post saying it's not interpreted -- instead of the comment taking time during bytecode interpretation it's just taking time during compiling the source into bytecode...

Net change zero... though at least YES, there is relief in the form of eAccellerator, APC, etc, etc... It's just not bulletproof relief.

[paul_wilkins]

The idea of comments is to save time later on.

You should write your code and comments in such a way than when you or anyone else needs to do any changes to the code a year from now. Then you will undertand what the code section does the second you read over it.

Much of the time, comments are used because the code is not clear enough to explain what happens on its own.

The best way to resolve that problem is not to add comments, but to refactor the code so that it becomes clear enough to explain what is happening.

Can you tell that I've been reading the Clean Code book lately?

[deathshadow60]

The best way to resolve that problem is not to add comments, but to refactor the code so that it becomes clear enough to explain what is happening.

EXACTLY... and why I laugh whenever I hear the pathetic cop-outs of calling it "arbitrary formatting", "wastefully long variable or function names" or "rigid rules that aren't worth following" -- 27 years later and I'm STILL quoting the catholic nun who taught me to do something more than hobbyist level ASM/Basic on that subject -- "Vomiting up code any old way"

Off Topic:

(Funny that, a Jew taking coding lessons from a Catholic Nun. We get a protestant in there and we'd have a decent "walked into a bar" joke)

It's also why I laugh and go "what are you thinking" whenever I see code like this:

// Go and get our next record
function ggi() {

If it was named something proper, like say "getNextRecord" it wouldn't need the comment. Of course I REALLY love it when you point this out, and they say "oh, it's less to type" ... DUH... (because of course the comment is so much less text) It's why I'm alway pointing people at that article on the IBM linux dev site.

Six ways to write more comprehensible code

But you'll always have the people who ignore the better coding practices -- their loss... and their clients loss... and the loss of whatever poor slob has to clean up their mess. JHVH forbid things like indenting styles, naming conventions, style guides or any of the dozen other methods for writing cleaner, clearer easier to maintain code be followed.

No, instead let's rely on tools to handle all that when computers aren't smart enough to do it; if they were we wouldn't need programmers. Many of such tools (like say pretty print) having been invented NOT to clean up the code of competent programmers, but as a means for competent programmers to have a baseline to clean up code written by the inept.

Can you tell that I've been reading the Clean Code book lately?

Can't say I've heard of that one, but it sounds good. Have to add that to my library.

[Stomme poes]

If you're using vi.

If you're using an IDE, the former will be easier to read/edit due to syntax highlighting, tag matching, code completion and HTML error checking. Not to mention the code you demonstrate would likely be surrounded by large chunks of HTML.

You haven't used vim I take it? : )

If I wanted to spend hours dicking around on the command line for functionality I've had with two or three clicks since windows 3.1,

If you had spent hours dicking around on the command line, you'd have the functionality *typo! of the several clicks with one line. At least, that is what I propose : )

[paul_wilkins]

If you had spent hours dicking around on the command line, you'd have the functionalirt of the several clicks with one line. At least, that is what I propose : )

The problem with trying to teach people to use a command line, is that it involves a much hated aspect of learning, and that is that they have to remember things.

When using a mouse, they can be visually prompted along the way, which is a much lazier and slower way of doing things, but it's easier than that remembering stuff that you have to do on the command line.

[Stomme poes]

which is a much lazier and slower way of doing things, but it's easier than that remembering stuff that you have to do on the command line.

Yeah, that's why I forget all the cool vi commands I see on the golf course... I'm always like, oh I have to do X... I know I just saw a command to do that yesterday!
Luckily there are 30 other ways to do it... or I could even just use the mouse if I'm really under the weather : )

[samanime]

^ agrees with Stomme. I can type a few hundred characters in about the same time it takes me to take my hand off the keyboard, put my hand on the mouse, move the mouse, click the mouse, then reposition my hands on the keyboard.

As for the topic of this thread itself, I'm kind of on the fence.

I think that documentation is very important, especially for developers coming in that aren't necessarily experienced with the project. If you're coming in to a project with 10,000 lines of code, even if every line of code is written in a clearer-than-crystal way, it still takes time to wrap your head around how various things interact with each other.

At the same time, I also agree that if you have to write a few lines of comments to explain your few lines of code.... there is something wrong with those few lines of code.

Now, as far as the performance of comments in code, I think they cause a minimal performance hit, at best. If I was on a real computer (and not on a laptop in a hotel in Vegas on business =p), I'd test this out. If this topic is still alive next week, I probably will. You could test this by writing two identical files, put a few hundred lines of comments in one, then include the files repeatedly by timing each one. Average the times and see if there is a statistically relevant time difference.

[paul_wilkins]

Now, as far as the performance of comments in code, I think they cause a minimal performance hit, at best. If I was on a real computer (and not on a laptop in a hotel in Vegas on business =p), I'd test this out. If this topic is still alive next week, I probably will. You could test this by writing two identical files, put a few hundred lines of comments in one, then include the files repeatedly by timing each one. Average the times and see if there is a statistically relevant time difference.

You'll find that even when you get in to the extremes, such as several hundred lines of comments along with three lines of actual code, that performance testing shows an incredibly tiny difference of time that relates to this.

In reality, good comments more than outweigh the time it takes for the processor to ignore them.

Instead of focusing our personal attention on the minuscule impact of CPU time, our time may be more productively spent by focusing on the issue of writing good comments, or on improving code so that comments become less necessary.

[Stormrider]

I agree that code should be self documenting, good variable names etc, but this is all distracting from the original discussion of deathshadow's claims that adding comments slows down the server too much - which is a load of rubbish!

[paul_wilkins]

I agree that code should be self documenting, good variable names etc, but this is all distracting from the original discussion of deathshadow's claims that adding comments slows down the server too much - which is a load of rubbish!

Too much? I wanna see numbers for that kind of claim.

[Stormrider]

Indeed, I would love to as well. It's not my claim, but apparently using PHP comments means you 'FAIL HARD' - see the first posts in this thread.

[Stormrider]

Ha, ironically, the article deathshadow linked to earlier on the IBM website even says this:

Tip 5: "Premature optimization is the root of all evil." - Donald Knuth


I didn't make up the above sentence. But you can find it on Wikipedia, so it must be really smart.


Unless you are trying to make people suffer, your first goal, when writing code, should be clarity. Simple code is faster to write, faster to understand when you return to it later, and faster to debug.

[paul_wilkins]

Ha, ironically, the article deathshadow linked to earlier on the IBM website even says this:

That article was a really good read, and has many jewels of wisdom that need to be proselytized on a more frequent basis.

[Stormrider]

Yup, I agree, it's generally the way I try and code anyway. I also have the Clean Code book you mentioned earlier, it's a good read.

[Michael Morris]

Much of the time, comments are used because the code is not clear enough to explain what happens on its own.

The best way to resolve that problem is not to add comments, but to refactor the code so that it becomes clear enough to explain what is happening.

Yes, because every job has unlimited time with unlimited budgets.

Refactoring is great when its an option - but in the real world with deadlines adding features to less than well thought out code then documentation by comments is often your only choice.

[TomB]

Also, quite often, refactoring will cause added complexity, sacrificing clarity for flexibility and better separation of concerns. The added complexity doesn't necessarily make the code easier to follow.

[paul_wilkins]

Also, quite often, refactoring will cause added complexity, sacrificing clarity for flexibility and better separation of concerns. The added complexity doesn't necessarily make the code easier to follow.

That seems to be going in the opposite direction. The whole reason for refactoring in the first place is to increase clarity so that the need for comments is reduced.

If If you're finding that your code becomes complex and opaque, a step back clearly needs to be taken.

[TomB]

That is not always the case.

For Example: Introducing a factory to handle object creation instead of calling "new Object" directly. The logic has been abstracted away to improve flexibility, testability and dependency issues. However, it's no longer obvious exactly what type of object has been created, sacrificing clarity.

[deathshadow60]

I agree that code should be self documenting, good variable names etc, but this is all distracting from the original discussion of deathshadow's claims that adding comments slows down the server too much - which is a load of rubbish!

That it slows it down at all means that POINTLESS comments should be avoided -- that's all I'm saying... DO comments imbue a penalty on the parser time? YES. Do comments make it take longer to load from disk? YES.

It is about balancing useful against the penalty; answer me this, do you consider this a meaningful comment:

// HTML
    <?php /* ===================== START BLOCK ======================== */ ?>
 <div id='new_left'>

Even if the comment itself were useful (opening a div is the start of a block, I'm shocked) all those equal signs are a waste of code.... It doesn't say what block is being started making it LESS useful than the DIV, the closing one doesn't say what block is being ended, making you have to scroll back up to find it -- net result is a POINTLESS comment that was a waste of time to type, waste of time to load from disk, waste of time for the parser to have to ignore when converting it to bytecode.

That's pretty much my point. I wouldn't have a problem with it if the comments were USEFUL. (which is why I'm not entirely happy with the title chosen for the thread split -- it's a MINOR part of what I was responding to)

Go futher down his code, and you have comments like this:

header("Content-type: text/css;charset:UTF-8"); http://www.barelyfitz.com/projects/csscolor/

What on earth does that URL have to do with sending content-type?!? Pointless meaningless comment.

if(0){include'style.class_colors.php';} http://www.typefolly.com/

Again, huh?!? Meaningless comment that makes no sense. Of course, this is the OTHER thing I took it to PM over; the condition is always false so this code would NEVER run; why is this line even there?

if(1){include'style.style_fonts.php';}
if(1){include'style.style_dimensions.php';}

Always true, why do these have if statements?

if(0){include'user_1.php';}// blood,tangerine,banana,ocean,grass,coal
if(1){include'user_2.php';}// blood,tangerine,banana,ocean,grass,coal

What on earth do those comments have to do with the user includes -- are those usernames or something?

Comments should answer questions, not create more of them.

That it's using php to output CSS (say goodbye to client-side caching) is just a further head scratcher since IMHO there's no legitimate reason to EVER do that... god forbid the end user have to edit CSS... or write your changes to a static file instead of wasting processing time creating it on every request. That's just as bad as presentational markup at that point.

I'm seeing the EXACT SAME ATTITUDE on this I encounter with HTML in terms of valid semantic markup; "Oh it's so insignificant an impact" and "Oh it's too much effort for the return"... too much effort to NOT write wasteful/pointless comments... Too much effort to NOT do something? It's akin to the "It's too much effort to follow a few simple rules to continue to make my pages useful on IE6 and even IE 5.5"

It does NOT take extra effort to go "hey, maybe I shouldn't fill a line with 90% equal signs or asterisks"... it does not take extra effort if you bother following coding conventions that prevent you from making mistakes in the first place. It shouldn't take extra effort to put meaningful names on things or to bother using the enter and tab key to make blocks of code logic clearer.

But you always have the people who claim it do, and just "vomit up code any old way"... Just look at the source code for turdpress for proof enough of that.

... and "simple code" doesn't mean pointless code with vague/misleading/nonsensical comments. Premature optimization and bothering to follow a style guide making clear code are two separate things. Simple practices that reap MULTIPLE benefits (not just optimization) are NOT evil JUST becuase a slight code speed increase are a SMALL part of it. (Have we mentioned how the thread split title pisses me off and how you guys are focusing on a SMALL part of what I was originally saying?!?)

I should have just posted the PM in the original thread and to hell with dragging it off topic.

READ MY ORIGINAL POST

Now, PHP is a two stage bytecode interpreter; which is to say that it does a byte-code style compile before executing, but the inital parse still takes overhead for comments which is why stupid pointless comments (like a row of nothing but asterisks) should be avoided... Certainly a code caching accellerator (APM, eAccellerator) helps by caching the byte-coded version, but if your code ends up flushed from the cache those comments will incur their penalty again.

All I'm saying is don't put stupid pointless comments in -- is that SO HARD or TOO MUCH EFFORT?!? Sheesh.

[Michael Morris]

Hate to break it to you ds, but computers have more than 1K of memory these days. There's saving space, and then there's useless pedantry