|
Ravi Bhavnani wrote:
Even at the expense of readability? I suggest (a) first get it to work (2) then make sure the code's readable and finally (3) optimize for speed and resources.
I completely agree with your priorities, and FWIW, don't think Sreejith intended to imply ignoring readability, but was just emphasising that we should try to reach step #3.
And that's what concerns me about what some of our coworkers don't do. By nature, especially under time pressure, we often don't reach step #3, and all too often not even step #2! Once something works, the pressure to move on is strong, and it's often rare that we have the time, let alone remember, to go back and tidy things up.
I'm sure many of us do the following intuitively, but for those that don't, this is my more verbose description of the same priorities:
.1) Give a moment's thought to how to organise the code for reasonable efficiency.
.2) While coding, ensure names are understandable to one's self and others, and comment what less obvious ones are for (this discipline does not waste time, since it saves enourmous amounts of time in the long run).
1) Get it to work.
1.1) While pondering how to make changes (for efficiency or just to get things working), write your thoughts out in a comment. This seeming annoyance can actually save time, since one is forced to describe the situation, which clarifies thoughts).
2) Make sure the code is readable. If steps #.2 and #1.1 were actually done, there's little to do here.
3) Optimize for speed and resources. If step #.1 was done, this step is much, much easier, and often a lot less needs to be done. If forced to skip this step or forgot about it, there will still be fewer rants from quality control, bosses, and users.
Just my 50 cents worth...;)
|
|
|
|
|
Jeff J you pointed what i mean really. Thanks.
As you said now a day programmers are satisfied once their code got required result. They are least bothered about how much it will use the resource. And if try to consize how much i can free the resource.
Sreejith Nair
[ My Articles ]
|
|
|
|
|
When money and time are important this is usually the way my priority list runs. But good coding practices minimize the time required to optimize the final product.
Removed... Too many questions
|
|
|
|
|
diilbert wrote:
good coding practices minimize the time required to optimize the final product.
Very true.
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
This is a true story, beleive it or not...
I was using the Metrowerks compiler for ColdFire version 3.2.2 and my embedded application was doing okay. Total size was 206 KB.
Then we started working on a new project, going from 5206e to 5280 microcontrollers, my old compiler does not support that platform, also, I needed a RTOS and TCP/IP stack from a vendor that required version 4.0 or up of the compiler.
So, I got myself a brand new US $ 2500 "upgrade" package with version 5.0 and, behold, my code is now 335 KB!
I looked at the disassembled result, and noticed that the compiler is now very reluctant to make use of the (plentiful) registers!
I spent quite a lot of time scanning the compiler options and calling tech. support, to no avail: "the old compiler had some stability issues" with optimal code generation, so now they have an issue with bigger compiler output!
It seems to me, that the 1st level of optimisation here is that the compiler does not do its job very well anymore.
I have yelled and screamed and made a fool of myself. Still, I keep thinking that this is not acceptable.
What do you think, I should rewrite my (considerable) c / c++ project in assembler ?
|
|
|
|
|
Another platform to avoid, especially in embedded SW development, is AppForge's crap products.
They promise portability across platforms, but in reality, unless you only do an app with a few buttons and a scrollbar, there's headaches aplenty.
And when we scream at the mile-wide gaping holes (ahem, "limitations") in the API, nobody cares at the other end.
A shame.
|
|
|
|
|
When I write some new code or maintain some old code, I usually aim to make it as simple to read as possible, I go out of my way to make my code very easy to understand, and it usually pays off.
|
|
|
|
|
surly this will help others who watch this code. Apart from this, you will also get free to read it fast.
Sreejith Nair
[ My Articles ]
|
|
|
|
|
True Story:
I work at one of the largest contract electronics manufacturing companies in the world, and one of my responsibilities is to develop bar code label programs for our customer's products. When I first arrived I was horrified to find out that all of their bar code programs are still done on old DOS 16-bit machines, which are not networked. They literally have 200+ DOS PC's all holding mission critical data, which is not backed up anywhere, on old machines that barely run. When I looked at the programs, I was skeptical that the person who actually wrote them had a recent Computer Science degree, since the code was written at a level I would expect of a high school student.
What added insult to injury was this person was going to be my supervisor and I was required to program in the exact same manner that she did, and in so doing it usually took on the order of 3 days to write any given program. Over time I worked on improving the readability of the code and changing it so that all the highly repetitive sections are put into standard function call (all pretty basic stuff from CS 101). These improvements led to a library that when used allowed the same programs to be written in 3 hours instead of 3 days, and could be readily understood by people with only a basic understanding of C++. When my supervisor found out, she went ballistic, even though there was only ever 1 bug in the entire system (which took only 5 minutes to find and fix) she went to her boss and tried to claim that I had destroyed their entire system and none of the programs worked. I got chewed out BIG TIME even though I could prove that the programs' functionality had not been changed, only its readability, size, and speed. All programs that use the new library work great, but now I am only allowed to use it for programs that I write, and cannot change existing programs. My supervisor still codes in her old fashion. Funny, in the same time period of 3 months I have finished 20 projects and she has only finished 1, and it has lots of bugs. Yet she still remains adamant that her way is superior and that my method is totally wrong, go figure.
Daniel Petersen
|
|
|
|
|
At the end of the day, you probably feel good about what you are doing, and expect someone to take over your code w/o going through the headaches you mention you had, when you started to dig in the old code.
When I started, too, I was blammed for "rewriting everything". (Of course, I did not rewrite everything, but thats another story)
|
|
|
|
|
...Not necessarily waiting until it's "critical", but not right off the bat, either. For UI work, if response time doesn't "feel" right (on the typical system), it'll get optimized until it does. For all other systems, if it'll waste someone's time, it gets changed to waste less time.
Rule of thumb: if i want (or get asked) to add a wait cursor or progress dialog, it could probably use some optimization. Otherwise, i'm better off spending time elsewhere.
"The time has come," the Walrus said,
"To talk of many things..."
|
|
|
|
|
As an embedded programmer, I too find stock functions too inefficient. I have a slew of numeric<->string converters for such systems (and desktops), that are fractions of the size of printf-like funcs, and several hundred percent faster. Sometimes some assembly is required (pun intended), but if I can use a decent optimising compiler, I can get away without it.
I've had bosses that complain I "waste too much time on such things", while I watch other waste weeks trying to figure out why their MCU doesn't respond within the required timeframe! They come to me to fix things, and as such "I'm" not producing fast enough. Go figure.
Cheers
"There's intelligence out there, somewhere..."
|
|
|
|
|
"I've had bosses that complain I "waste too much time on such things", while I watch other waste weeks trying to figure out why their MCU doesn't respond within the required timeframe! They come to me to fix things, and as such "I'm" not producing fast enough. Go figure."
You friiiiiiiennnnnnnnd, buddyyyyyyyyyyy of misfortune !
Kochise
In Code we trust !
|
|
|
|
|
I've read this article http://www.flounder.com/optimization.htm written by J.M. Newcomer and I think I'm not experienced enough to switch on the optimization buttons of my compiler.
best regards
Thomas
|
|
|
|
|
<snort>
Yeah, after reading some of Joe's articles, anyone could end up feeling completely incompetent, and that all coding duties should be turned over to Joe, who did every task imaginable back on PDP-11's in the 1970's.
|
|
|
|
|
Hi,
thats it! With your words.... everything is said! Let's stop programming and let it all for Joe and maybe for Paul Di Lascia IF Joe needs some spare time to sleep.......
best regards
Thomas
|
|
|
|
|
And I will continue to do so, until the number one complaint changes from "Damn, this thing is slow!" to something else.
IME, complaints about speed and stability are the most often heard complaints, both of which, IMHO, are usually due to sloppy or lazy development practices.
Peace!
-=- James
Tip for inexperienced drivers: "Professional Driver on Closed Course" does not mean "your Dumb Ass on a Public Road"! Articles -- Products: Delete FXP Files & Check Favorites
|
|
|
|
|
James R. Twine wrote:
And I will continue to do so, until the number one complaint changes from "Damn, this thing is slow!" to something else.
That's great! I feel your pain.
|
|
|
|
|
I will frequently optimise any code that works over the wire... there are still a lot of slow networks out there...
An expert is somebody who learns more and more about less and less, until he knows absolutely everything about nothing.
|
|
|
|
|
The golden rule is to use a simple non-optimised algorithm initially, and only optimise it later if it turns out to be too slow.
However, sometimes I optimise from the begining if it's obvious that that non-optimised version is going to be inadequent. Also, if the optimised code takes no additional effort to code then I always use the optimised version.
|
|
|
|
|
I optimize exactly once. If I need to optimize an algorithm, I do it. And then that's how I'll write that algorithm from that point on, unless I really can't for some reason. This applies to patterns (algorithms with loose semantics).
I mean, why not reuse something that's proven to work reasonably fast?
--
Weiter, weiter, ins verderben.
Wir müssen leben bis wir sterben.
I blog too now[^]
|
|
|
|
|
Most optimizations can be down to good programming style.
Always using const references for parameters where appropriate etc.
Calculating intermediate results only the once etc.
Other than that, with todays PC speed, I dont think you really have to worry about it.
If you vote me down, my score will only get lower
|
|
|
|
|
Here's a question:
Roger Allen wrote:
Always using const references for parameters where appropriate etc.
I work with a guy who's a rabid over-optimizer. He also reviles the use of const, saying that he does not want to place any restrictions on his implementations.
I've given up on trying to get him to use const as a matter of good coding style, or as a courtesy to others on the team; however, I've thought about approaching this from the optimzation standpoint - but I don't fully understand how const references can improve code performance. Can you enlighten me on this, or point me to some references on the subject?
Thanks -
|
|
|
|
|
He can't be a rabid over-optimiser if he doesn't use const, he probably just fancies himself as an optimiser.
Const references are one of the most important optimisation hints, without which, the [compiler's] optimiser may just toss dice to decide which objects and pointers to keep in registers. VC++ no longer honours the register keyword, so const is all we have left.
To the optimiser, const is somewhat the opposite of register; instead of keeping the object in a register, it may specifically decide that object does not need to be, since it never changes. Thus, other objects are more likely to be kept in registers. Since more than one operation can execute on modern chips at once, things can be assigned from stack vars with little or no loss if there's something else that can be done in the meantime. But that's only part of the story.
const objects may also be temporary, can be calculated as needed (sometimes concurrently with other operations, to promote parallelism, which can double efficiency), and provide several other hints. In other words, const is an invaluable optimisation hint. If this guy really loves to optimise (he really should be judicious, since many things are done automatically by the compiler), he would step through critical loops in disassembly view as I do, and notice the benefits.
Personally, I've found const saved my arse many times, too. In coding frenzies (read "deadline"), I've occassionally had the compiler squawk that I tried to modify a const object, which forces me to fix it and avoid nasty bugs.
Cheers
|
|
|
|
|
IIRC, const references/const objects are generally not more optimized than ordinary objects. I read an article on this by some C++ hot shot, but I don't remember where I read it.
const-correctness is a design strategy, enforcing read-only behaviours.
const int and the like are however replaced with compile time constants.
When I do pure C++, I try to use const as much as possible. It makes my code safe from feeble coding attempts on a late friday afternoon. However, I've been doing a lot of COM lately, where I can't use const in all it's splendor. I miss const.
--
Weiter, weiter, ins verderben.
Wir müssen leben bis wir sterben.
I blog too now[^]
|
|
|
|
|