1. About speed
- Posted by ken mortenson <kenneth_john at y?h?o.com>
Jun 02, 2008
-
Last edited Jun 03, 2008
I need to answer the other part of your question.
Jeremy Cowgar wrote:
> The variables that while cond2, cond3,
> etc... need to access from the original calling function?
Of course, in my example you'd have to pass in any values needed by the
internal conditions which is slower. I've seen this argument taken to
the extreme where NO parameters are passed, just make all variables global.
I'm sure you see the problem with that.
I don't know if you know the history of Microsoft basic compilers.
Originally GWBasic (an interpreter) used line numbers. In the 1980's we
had BASCOM where you could use labels. What power and freedom that was!
I loved it and it was fast (I might have mentioned that I turned a 16 hour
report into a 30 minute report using it to process millions of customers.)
Then came QuickBasic which was much slower than BASCOM. VB was slower
than QuickBasic. I've stayed away from dotNet, but I imagine it's slower
too. The only thing that's saved us is that the hardware keeps getting
incredibly faster.
Bottom line Jeremy, speed is not the biggest issue generally. If you want
really fast, hand coded machine language is the way to go, although
optimized C is still a better starting point.
Me, I just want to use one language. Actually just one dialect of one
language. Every time I have to look at a manual, that's the speed issue
that bothers me most.
Most speed issues can be addressed by more inline code. It's the last thing
I would optimize for because generally it means making your code less
readable. I haven't used or missed gotos in decades.
I could recode the example with the additional constraint of no calls, but
the result wouldn't be something I'd normally do.
2. Re: About speed
ken mortenson wrote:
> Most speed issues can be addressed by more inline code. It's the last thing
> I would optimize for because generally it means making your code less
> readable. I haven't used or missed gotos in decades.
>
> I could recode the example with the additional constraint of no calls, but
> the result wouldn't be something I'd normally do.
I completely disagree. If I don't care about execution speed, then Euphoria
is probably not the language best suited for the project at hand.
Euphoria has had exactly two primary selling points since it's beginning:
1. It runs faster than any other interpreted language on the market (and
faster than most compiled languages), and
2. It has a minimal command set leading to a short learning curve.
Both points have been debated ad infinitum over the past decade and a half
as to their accuracy, but nevertheless, they have been the points which at
least drew people to investigate the language (that and the clever use of
search engine keywords). The second point is passe. The first point remains
valid.
I stick with Euphoria because it's faster to code in and faster to execute
than Java. Remove either of those, and Euphoria no longer has a niche to
play in. If you want Euphoria to look like Python, then save yourself the
effort and just use Python - it's already been developed. If you want it to
be Lua, then just use Lua - it too has already been done. If you want to
use Euphoria, then use it for what it is. Improve it slowly - it isn't
perfect, and never will be. But don't sacrifice what makes it unique in the
process.
3. Re: About speed
Michael J. Sabal wrote:
>
> I completely disagree. If I don't care about execution speed, then Euphoria
> is probably not the language best suited for the project at hand.
When did I say I didn't care about execution speed?
I don't use Java today because it never seemed ready for prime time because
it was too slow. Other people love Java but I'm not one of them.
My point is that you address speed issues when they become a problem, not
before. I suppose you disagree with this statement, but 'completely' I
find hard to believe.
You can never even tell if you have a speed issue until you run your code.
4. Re: About speed
ken mortenson wrote:
> You can never even tell if you have a speed issue until you run your code.
I've heard this many times. I am no speed freak, but there are many things that
I *know* will cause a speed problem. If I blindly do all of those things in my
app and it takes 10 seconds for, say, a file import and I'm happy with that, why
go back and edit?
However, I know certain things will cause slow downs. Now, I develop the first
time not using those certain things. Now, the first time around my import takes 5
seconds. No more/less code, just good common sense.
That's all I am speaking about when I am talking about functions. Many people
say, refactor, refactor, refactor. Oh no!!! Your function is more than 3 lines
long!!! Refactor!!! What? You have nested loops!??!?!? Refactor! Make more
functions.
You said none of the above, I am not pointing toward you, but I am simply saying
there are things you can do and should do from the begining if you are worried
about speed or not.
Going back and fixing speed issues should be done when you've done a good job
programming and it's still too slow. All too often the idea of code first,
optimize later means to most people, code sloppy, fix if necessary. I'm not at
all for that, but I've seen it all too many times in the name of optimizing early
is evil.
--
Jeremy Cowgar
http://jeremy.cowgar.com
5. Re: About speed
ken mortenson wrote:
>
> I need to answer the other part of your question.
>
> Jeremy Cowgar wrote:
> > The variables that while cond2, cond3,
> > etc... need to access from the original calling function?
>
> Of course, in my example you'd have to pass in any values needed by the
> internal conditions which is slower. I've seen this argument taken to
> the extreme where NO parameters are passed, just make all variables global.
>
> I'm sure you see the problem with that.
>
I probably would take it to the extreme and simply include the 3 or 4 lines that
the function would do right inside of the loop and use the new 4.0 features to
exit which ever loop I wished. One thing is for sure, most of the programs I
write have zero global variables. Once in a while I'll do something dirty in
utility type apps and have a global database handle or something.
--
Jeremy Cowgar
http://jeremy.cowgar.com
6. Re: About speed
Jeremy Cowgar wrote:
>
> ken mortenson wrote:
> > You can never even tell if you have a speed issue until you run your code.
>
> I've heard this many times. I am no speed freak, but there are many things
> that
> I *know* will cause a speed problem. If I blindly do all of those things in
> my app and it takes 10 seconds for, say, a file import and I'm happy with
> that,
> why go back and edit?
>
> However, I know certain things will cause slow downs. Now, I develop the first
> time not using those certain things. Now, the first time around my import
> takes
> 5 seconds. No more/less code, just good common sense.
>
> That's all I am speaking about when I am talking about functions. Many people
> say, refactor, refactor, refactor. Oh no!!! Your function is more than 3 lines
> long!!! Refactor!!! What? You have nested loops!??!?!? Refactor! Make more
> functions.
>
> You said none of the above, I am not pointing toward you, but I am simply
> saying
> there are things you can do and should do from the begining if you are worried
> about speed or not.
>
> Going back and fixing speed issues should be done when you've done a good job
> programming and it's still too slow. All too often the idea of code first,
> optimize
> later means to most people, code sloppy, fix if necessary. I'm not at all for
> that, but I've seen it all too many times in the name of optimizing early is
> evil.
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
Sloppy code sucks, but see my sig.
Of course, I used to have a sig that espoused the virtues and vices of levels of
indirection.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
7. Re: About speed
Jeremy Cowgar wrote:
> However, I know certain things will cause slow downs. Now, I develop the first
> time not using those certain things.
I certainly understand this. A programmer should learn from experience and
develop good habits that usually means writing faster code to begin with.
> Many people
> say, refactor, refactor, refactor. Oh no!!! Your function is more than 3 lines
> long!!! Refactor!!! What? You have nested loops!??!?!? Refactor! Make more
> functions.
Parrots make bad programmers too. I once had a loud discussion with a
fellow programmer right outside the owners office not long after I hired on
at a company. He was telling me about how 5 staff programmers had spent six
months figuring out how to do something and that I was doing it wrong. It
turns out I had written something that was functionally equivalent to what
they'd spent 2.5 man years (yes, I know the man years are not quite accurate,
they did do other things during that time, but still it took them six months)
I did it in an afternoon, but I'd written it with inline code instead of
factoring out certain tests. There is something to be said for, "do it
because that's the way we do it." but I've always felt a bit of thought
and reason should occasionally be injected (in small enough amounts so that
no one gets hurt of course. 
I did end up factoring out the tests
because that was better. Speed wasn't really an issue because it was
plenty fast for it's purpose, which was field level validation.
Oh, my boss did call us into the office to tell us he liked the energy level.
That was strange. He was always talking about building cathedrals instead of
bricks.
> Going back and fixing speed issues should be done when you've done a good job
> programming and it's still too slow.
You're right. That's all I'm saying as well.
You make a lot of sense, Jeremy. I expect we will continue to be apart on
some of the details.
"Science is the belief in the ignorance of experts." - Richard Feynman
