Someone confirm/deny what I was told

Post #116,564 by drewk 9/4/03 11:07:16 AM Reply	Someone confirm/deny what I was told Rule of thumb: If you feel you need to add a comment for a block of code, then you probably should turn that chunk of code into an appropriately named function. A developer I used to work with disagreed with this on the grounds that calling a function, and potentially passing the necessary data, incurred enough overhead to become significant to execution time. In a hypothetical 500-line file, how much difference might there actually be between doing it in a single 500-line pass, and doing it in 50 10-line functions? Does the answer differ if you're using a compiled vs. an interpreted language? Are there just too many variables for there to be a general answer to this? In any case, my experience says that the readability/maintainability gain of breaking it up more than makes up for possible efficiency gains. If you can make one developer 10% more effective, you can add a fairly decent box to your cluster every year to improve execution speed. === Implicitly condoning stupidity since 2001.
Post #116,565 by admin 9/4/03 11:10:36 AM Reply	Depends on the language PL/SQL function calls, for example, are relatively slow. This makes a noticeable difference on a box that already runs its CPUs near maximum. :-P If you do have the CPU to burn, however, the maintenance benefits are well worth it. There are those, however, who cannot be convinced of this no matter what. "But, it's all right in one place! And all the variable declarations are right at the top! How would functions be better?" (actual response, by the way, to a suggestion that we use more functions instead of 4000-line long procedures with 300 variables at the top...) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #116,568 by deSitter 9/4/03 11:17:50 AM Reply	Re: Depends on the language (actual response, by the way, to a suggestion that we use more functions instead of 4000-line long procedures with 300 variables at the top...) GAH! Cobol! -drl
Post #116,570 by tuberculosis 9/4/03 11:21:45 AM Reply	Sounds more like FORTRAN Cobol has copy (you know - like include) files. Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations. --AndyBower
Post #116,571 by admin 9/4/03 11:29:09 AM Reply	Yes, very FORTRANish I worked with a guy at Coopers & Lybrand once who was an economist by education. He taught himself how to program C. So, in this program he wrote, main() called proc(), which was about 5000 lines long with numbered variable names instead of structs. Gah. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #116,577 by drewk 9/4/03 12:05:31 PM Reply	Different reason for that, I believe When I was learning PL/SQL I read that one of the disadvantages was that the PostgreSQL optimizer couldn't read into the functions. So putting all the logic into a larger query gave the optimizer more chances to build a query plan, whereas using a function removed the options. === Implicitly condoning stupidity since 2001.
Post #116,589 by admin 9/4/03 1:28:51 PM Reply	We did testing... Multiple function calls in loops, etc. While there may have been a query plan issue at some point with packages, I doubt that's the case any longer. Everyone, but everyone, says to put your DML in a function. BTW, did you mean the Oracle optimizer...? ;-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #116,601 by drewk 9/4/03 2:42:49 PM Reply	D'oh! Oh yeah, real PL/SQL. I was just using those books because they were better than the online docs for PL/pgSQL. === Implicitly condoning stupidity since 2001.
Post #116,602 by admin 9/4/03 2:49:28 PM Reply	ROFL. Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #116,572 by tuberculosis 9/4/03 11:30:59 AM Reply	I have a 1GHz laptop My first computer was an 8MHz Mac II. Tell me the cost of calling a function still matters 99.99999999999999999% of the time. If it does - you can still usually make it look like a function with a macro or something. Scott's SQL example is a degenrative case. Realtime systems in tiny machines might be another one. A good quote I've seen is "The number of programmers who think their software has high performance requirements is at least two orders of magnitude greater than the number of programmers that actually have high performance requirements". Call the freakin function - if the system runs too slowly, profile and inline appropriately. Smalltalk is dangerous. It is a drug. My advice to you would be don't try it; it could ruin your life. Once you take the time to learn it (to REALLY learn it) you will see that there is nothing out there (yet) to touch it. Of course, like all drugs, how dangerous it is depends on your character. It may be that once you've got to this stage you'll find it difficult (if not impossible) to "go back" to other languages and, if you are forced to, you might become an embittered character constantly muttering ascerbic comments under your breath. Who knows, you may even have to quit the software industry altogether because nothing else lives up to your new expectations. --AndyBower
Post #116,611 by Arkadiy 9/4/03 3:49:58 PM Reply	Or better yet The number of programmers who think that they have achieved high performance by scrificing readabilty is two orders of magnitude higher than the number of programmers who actually achieved high performance I had a piece of code with 3 functions, each with 3000-5000 lines. Turned out, it was dog slow. When rewritten with proper modularization and data structures, it became order of magnitude faster, function calls or not. -- Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them. --Alan Cooper. The Inmates Are Running the Asylum
Post #116,583 by JimWeirich 9/4/03 12:41:13 PM Reply	Re: Someone confirm/deny what I was told A developer I used to work with disagreed with this on the grounds that calling a function, and potentially passing the necessary data, incurred enough overhead to become significant to execution time. Hey, I think I used to work with the same guy. He also wanted to do everything in assembly for efficiency. Seriously! I remember him saying, "Jim, do you realize how many instructions are needed for a single FORTRAN CALL statement?" Gaaah. Another rule of thumb: Make it right, then make it fast. If excessive function overhead is a performance problem, then the "inline method" refactoring is only a menu pick and an OK button away. Lots of languages will inline automatically for you as well. C++ lets you manually specify inlining. The SmartEiffel compiler will automatically inline methods where it makes sense, and it will even handle inline "virtual" methods. -- -- Jim Weirich jweirich@one.net [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #116,619 by tuberculosis 9/4/03 4:12:07 PM Reply	Yeah that guy gets around! Because I know I worked with him too. ;-) Java is a joke, only it's not funny. --Alan Lovejoy
Post #118,608 by jb4 9/23/03 2:36:42 PM Reply	Puh-LEEEEZE! A developer I used to work with disagreed with this on the grounds that calling a function, and potentially passing the necessary data, incurred enough overhead to become significant to execution time. My rationalization alarm triggered on this one! Scott is, as usual, right in that various interpreted languages (PL/SQL, and I'd add VB in all its incarnations) can certainly load the overhead onto a resource-starved application. However, I work primarily in the real-time embedded space, where we are always starved for resources, with not enough process, not enough ROM and not enough RAM. In over 27 years, I cannot think of a single instance where modularizing the code resulted in a missed or overtime event, clobbered interrupt, or anything else that would indicate that "overhead be[came] significant to execution time." Basically, the guy is spounting bullshit jb4 Boy I'd like to see those words on a PR banner behind [Treasury Secretary John] Snow at the podium: Jobs and Growth: Just Wait. John J. Andrew, unemployed programmer; see jobforjohn.com

Welcome to IWETHEY!