Replies to post #17496 on The Question and Answer Board (IHUB)

[Bob Zumbrunnen]

Imagine debugging a few thousand lines of code that looks like this! I’ll digress here, but I once worked with a guy whose code was filled with comments like “Guess what this does.” and “I forgot how this works.”

I try not to use comments very much here but there's one particular routine that was fetching a whole board worth of messages 3 times to display one message; once for the message, once to figure out the "previous" link and once to figure out the "next" link. My comment until I changed it? "You've got to be sh*ttin' me!" <g>

That's really another area of programming altogether. If a system is small, you just write whatever's convenient for the programmer. Once it gets to be pretty large, you have to start tightening things up, sometimes a lot. When it gets huge, you start analyzing every little instruction you're making the machine carry out because a miniscule inefficiency (like the difference between arrays and pointers) can become huge when you're dealing with hundreds of thousands or even millions of iterations through a loop being performed by hundreds or thousands of people at the same time.

That kind of monkey is on my back right now, but getting the new webserver shrank the monkey.

I'd started storing lots of things in session variables because accessing something (like the width of each menu item) from the database on every single page is a lot more expensive than getting it from memory.

I'm going to have to use a different approach, though, because as powerful as our new webserver is, the day will come when we'll have to run multiple servers. And as I've already found, that's a nightmare when you're relying on session variables.

So now I'm going to (eventually) change things so that all the little stuff that has to be available during a user's session will be stored in hidden form fields and passed back and forth from screen to screen.

Hopefully, when that's completed and we're to the point we need multiple machines again, it'll be a lot simpler because it won't matter which machine each of your requests go to. With session variables, each request during a session has to go to the same machine. With hidden form fields, you should be able to bounce back and forth between machines and it won't matter.

I talked to Brad Dryer about it and the way he did it was to store only the user's login info on the user's machine, then use that to fetch everything else from the database on each page view. That won't work here because for each 1 thing he was fetching from the database, I'm probably fetching 10, thanks in large part to the My Interface and My Settings thing.

Example: while(*word) ++*(wordaarray+*word++-‘a’);

That's one of the things I hate about C. Perl, too, although it doesn't seem quite as bad to me. I love BASIC and all its dialects.

[sarals]

My point is this: one must be vigilant in choosing the correct library functions because they can often impact a program's performance profoundly. With my anagram solver, changing the code to use pointers cut execution time by one second. However, selecting different library functions to read my dictionary file cut execution time by twenty-two seconds. (Less than half.)

Good point... especially when it comes to io functions... that's usually where I find I can make the biggest improvements in performance. The other thing is loading often used data into memory.

Imagine debugging a few thousand lines of code that looks like this! I'll digress here, but I once worked with a guy whose code was filled with comments like "Guess what this does." and "I forgot how this works."

That's scary. It may be okay in one guy operation, but in a larger shop, comments are important and helpful to the next person looking at your code... or even to myself looking at it a couple years later. One guy I work with is the worst... very cryptic code with unnecessary complexity and few comments. It's a headache trying to figure out what he's doing.

I love the compactness of C/C++ but also try to make it readable and understandable to someone else. This comes from years of working in shops of 100+ programmers where they are not all the sharpest tools in the shed.



Sara

Go Giants! Go 49ers!