Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Optimization
31 views
Skip to first unread message
Frank Westlake
Jan 9, 2013, 10:16:19 AM1/9/13
to
I have not studied computer science academically and I have never worked
in the computer industry so this is merely personal opinion based on 28
years of programming experience. If anyone has information which
contradicts any specific point it may be interesting to read, but more
interesting will be information which contradicts my general principles.
I don't write well so if I seem to have misstated something please ask
for clarification.
I think the generally recognized goals of optimization are for speed and
for space, but as I see it there could be many more goals which may be
more important then those two. Herein I discuss those which I see as
being mostly relevant to this forum.
SPEED
Speed is important if your script needs to do something several times
per second, or if it is in a sequence of things which must all be done
as rapidly as possible. But speed optimization is sometimes harmful if
it unnecessarily hog the CPU.
SPACE
Space optimization with a script is hardly necessary anymore but it
could be useful if you are using it on portable media which has a very
small storage area.
PROCESSOR USAGE
This is what I think is most often the most valuable optimization.
Scripts performing maintenance in the background should not hog the CPU.
One way to optimize for low CPU usage is to have your script sleep
occasionally for about one second, or once every loop. This makes it
easier for the CPU to give time to other processes. A script optimized
in this way might be a very slow script.
MODULARITY
Write most of your code in subroutines which can be copied to and used
in other scripts. Or write them as separate files so that you need only
go to one place to make an improvement which will affect every script
which uses that subroutine.
READABILITY
This should probably be the most important goal for scripts presented in
this group. This is a learning environment and it is difficult to learn
from code if it is cryptically written. Writing for readability might
make the script perform more slowly or it might take up more space, but
the reader can make those changes if it becomes necessary. Any procedure
not discussed in the internal documentation (i.e. 'CALL /?') should be
explained in the script.
MAINTENANCE
Your script should be well documented and self documented. All static
values which may change some day should be set into variables at the top
of the script. The script should be readable and it should be modular.
A maintainer should not have to search through the script to find all of
a certain value and possibly change one which is unrelated, and the
maintainer should not have to search for every instance of a routine or
sequence of code.
My intent here has been to show that speed optimization may be of lower
importance in many situations and that it is most often going to be of a
lower importance for scripts in this group.
Frank
in the computer industry so this is merely personal opinion based on 28
years of programming experience. If anyone has information which
contradicts any specific point it may be interesting to read, but more
interesting will be information which contradicts my general principles.
I don't write well so if I seem to have misstated something please ask
for clarification.
I think the generally recognized goals of optimization are for speed and
for space, but as I see it there could be many more goals which may be
more important then those two. Herein I discuss those which I see as
being mostly relevant to this forum.
SPEED
Speed is important if your script needs to do something several times
per second, or if it is in a sequence of things which must all be done
as rapidly as possible. But speed optimization is sometimes harmful if
it unnecessarily hog the CPU.
SPACE
Space optimization with a script is hardly necessary anymore but it
could be useful if you are using it on portable media which has a very
small storage area.
PROCESSOR USAGE
This is what I think is most often the most valuable optimization.
Scripts performing maintenance in the background should not hog the CPU.
One way to optimize for low CPU usage is to have your script sleep
occasionally for about one second, or once every loop. This makes it
easier for the CPU to give time to other processes. A script optimized
in this way might be a very slow script.
MODULARITY
Write most of your code in subroutines which can be copied to and used
in other scripts. Or write them as separate files so that you need only
go to one place to make an improvement which will affect every script
which uses that subroutine.
READABILITY
This should probably be the most important goal for scripts presented in
this group. This is a learning environment and it is difficult to learn
from code if it is cryptically written. Writing for readability might
make the script perform more slowly or it might take up more space, but
the reader can make those changes if it becomes necessary. Any procedure
not discussed in the internal documentation (i.e. 'CALL /?') should be
explained in the script.
MAINTENANCE
Your script should be well documented and self documented. All static
values which may change some day should be set into variables at the top
of the script. The script should be readable and it should be modular.
A maintainer should not have to search through the script to find all of
a certain value and possibly change one which is unrelated, and the
maintainer should not have to search for every instance of a routine or
sequence of code.
My intent here has been to show that speed optimization may be of lower
importance in many situations and that it is most often going to be of a
lower importance for scripts in this group.
Frank
Stanley Daniel de Liver
Jan 9, 2013, 10:30:37 AM1/9/13
to
On Wed, 09 Jan 2013 15:16:19 -0000, Frank Westlake
<frank.w...@gmail.com> wrote:
> I have not studied computer science academically and I have never worked
> in the computer industry so this is merely personal opinion based on 28
> years of programming experience. If anyone has information which
Well experience trumps qualifications
<frank.w...@gmail.com> wrote:
> I have not studied computer science academically and I have never worked
> in the computer industry so this is merely personal opinion based on 28
> years of programming experience. If anyone has information which
>
> SPEED
no! If you need speed, you don't need batch!
> SPACE
not anymore
> PROCESSOR USAGE
Never thought of this; I assumed batch would not be applicable (see speed)
>
> MODULARITY
YES
>
> READABILITY
> This should probably be the most important goal for scripts presented in
Agree Strongly
> READABILITY
> This should probably be the most important goal for scripts presented in
>
> MAINTENANCE
Agree
QUICK TO KNOCK UP
well that's what it should be about IMHO.
--
It's a money /life balance.
Frank Westlake
Jan 9, 2013, 11:51:04 AM1/9/13
to
On 2013-01-09 07:30, Stanley Daniel de Liver wrote:
> QUICK TO KNOCK UP
>
> well that's what it should be about IMHO.
I don't understand that. "Knock up" in US English usually means "to make
> QUICK TO KNOCK UP
>
> well that's what it should be about IMHO.
pregnant".
Frank
Stanley Daniel de Liver
Jan 9, 2013, 11:46:41 AM1/9/13
to
foxidrive
Jan 9, 2013, 2:01:24 PM1/9/13
to
On 10/01/2013 2:16 AM, Frank Westlake wrote:
[el snippo and disregarded]
> My intent here has been to show that speed optimization may be of lower
> importance in many situations and that it is most often going to be of a
> lower importance for scripts in this group.
>
> Frank
Dave also added an extra character or two to your regimen of characters so he enhanced one of your recent
posts in functionality.
OTOH speed optimisation is one of Dave's interests - who is to say that others reading this group may not
also enjoy Dave's input.
--
foxi
[el snippo and disregarded]
> My intent here has been to show that speed optimization may be of lower
> importance in many situations and that it is most often going to be of a
> lower importance for scripts in this group.
>
> Frank
posts in functionality.
OTOH speed optimisation is one of Dave's interests - who is to say that others reading this group may not
also enjoy Dave's input.
--
foxi
Todd Vargo
Jan 9, 2013, 8:03:14 PM1/9/13
to
On 1/9/2013 10:16 AM, Frank Westlake wrote:
> I have not studied computer science academically and I have never worked
> in the computer industry so this is merely personal opinion based on 28
> years of programming experience. If anyone has information which
> contradicts any specific point it may be interesting to read, but more
> interesting will be information which contradicts my general principles.
>
> I don't write well so if I seem to have misstated something please ask
> for clarification.
>
> I think the generally recognized goals of optimization are for speed and
> for space, but as I see it there could be many more goals which may be
> more important then those two. Herein I discuss those which I see as
> being mostly relevant to this forum.
>
> SPEED
> Speed is important if your script needs to do something several times
> per second, or if it is in a sequence of things which must all be done
> as rapidly as possible. But speed optimization is sometimes harmful if
> it unnecessarily hog the CPU.
Speed is important where the user is waiting for a batch to complete
> I have not studied computer science academically and I have never worked
> in the computer industry so this is merely personal opinion based on 28
> years of programming experience. If anyone has information which
> contradicts any specific point it may be interesting to read, but more
> interesting will be information which contradicts my general principles.
>
> I don't write well so if I seem to have misstated something please ask
> for clarification.
>
> I think the generally recognized goals of optimization are for speed and
> for space, but as I see it there could be many more goals which may be
> more important then those two. Herein I discuss those which I see as
> being mostly relevant to this forum.
>
> SPEED
> Speed is important if your script needs to do something several times
> per second, or if it is in a sequence of things which must all be done
> as rapidly as possible. But speed optimization is sometimes harmful if
> it unnecessarily hog the CPU.
with a specific or intended result.
> SPACE
> Space optimization with a script is hardly necessary anymore but it
> could be useful if you are using it on portable media which has a very
> small storage area.
allowed' even today. Temp files which are specifically directed to
%TEMP% do not get placed on portable media, therefore I cringe every
time I see these unquantified requirements.
> PROCESSOR USAGE
> This is what I think is most often the most valuable optimization.
> Scripts performing maintenance in the background should not hog the CPU.
> One way to optimize for low CPU usage is to have your script sleep
> occasionally for about one second, or once every loop. This makes it
> easier for the CPU to give time to other processes. A script optimized
> in this way might be a very slow script.
operations. Sleeping many times in a batch still consumes CPU usage. One
might consider using START (or other method) to LOWer priority of
background batches.
> MODULARITY
> Write most of your code in subroutines which can be copied to and used
> in other scripts. Or write them as separate files so that you need only
> go to one place to make an improvement which will affect every script
> which uses that subroutine.
separate files as shared subroutines for other batches. Modification to
suit one batch could break several other batches. Separate subroutine
files can become deleted or permissions blocked on shared computers.
> READABILITY
> This should probably be the most important goal for scripts presented in
> this group. This is a learning environment and it is difficult to learn
> from code if it is cryptically written. Writing for readability might
> make the script perform more slowly or it might take up more space, but
> the reader can make those changes if it becomes necessary. Any procedure
> not discussed in the internal documentation (i.e. 'CALL /?') should be
> explained in the script.
have been posting as of late.
> MAINTENANCE
> Your script should be well documented and self documented. All static
> values which may change some day should be set into variables at the top
> of the script. The script should be readable and it should be modular.
> A maintainer should not have to search through the script to find all of
> a certain value and possibly change one which is unrelated, and the
> maintainer should not have to search for every instance of a routine or
> sequence of code.
code, rather than for general responses to help requests. This is not a
moderated group and not everyone has the amount of free time needed to
put that much effort into posting disposable code.
> My intent here has been to show that speed optimization may be of lower
> importance in many situations and that it is most often going to be of a
> lower importance for scripts in this group.
especially where the reader is going to run the code and wait for a
result, then you might want to include a disclaimer to this effect. I am
less likely to look at arbitrary code if I'm turned off by one that
interested me. YMMV
--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)
Carlos
Jan 9, 2013, 9:01:42 PM1/9/13
to
Frank. About optimization. A difference is in the programming language. Is compiled or interpreted?
In both always is possible write many lines of code for do the same. In the most cases is prefered the way most speed. But after this step, if the language is compiled, the optimization are left to the compiler. For example: Open Watcom C Compiler have these optimizations: Average space and time, Space optimizations, Time optimizations. If the language is interpreted is possible distribute two editions of your code:
production and development (example: jquery).
The development version have descriptive variable names, comments, idented lines. The production have short variable names, no comments, similar to ofuscated code. The idea is that the interpreter take the less time in read the files for interpret it to machine code.
In both always is possible write many lines of code for do the same. In the most cases is prefered the way most speed. But after this step, if the language is compiled, the optimization are left to the compiler. For example: Open Watcom C Compiler have these optimizations: Average space and time, Space optimizations, Time optimizations. If the language is interpreted is possible distribute two editions of your code:
production and development (example: jquery).
The development version have descriptive variable names, comments, idented lines. The production have short variable names, no comments, similar to ofuscated code. The idea is that the interpreter take the less time in read the files for interpret it to machine code.
billious
Jan 9, 2013, 11:06:30 PM1/9/13
to
On 9/01/2013 23:30, Stanley Daniel de Liver wrote:
> On Wed, 09 Jan 2013 15:16:19 -0000, Frank Westlake
> <frank.w...@gmail.com> wrote:
>
>> I have not studied computer science academically and I have never
>> worked in the computer industry so this is merely personal opinion
>> based on 28 years of programming experience. If anyone has information
>> which
>
> Well experience trumps qualifications
>>
>
And sadly politics trumps both...
> On Wed, 09 Jan 2013 15:16:19 -0000, Frank Westlake
> <frank.w...@gmail.com> wrote:
>
>> I have not studied computer science academically and I have never
>> worked in the computer industry so this is merely personal opinion
>> based on 28 years of programming experience. If anyone has information
>> which
>
> Well experience trumps qualifications
>>
>
billious
Jan 10, 2013, 1:56:32 AM1/10/13
to
On 9/01/2013 23:16, Frank Westlake wrote:
> I have not studied computer science academically and I have never worked
> in the computer industry so this is merely personal opinion based on 28
> years of programming experience. If anyone has information which
> contradicts any specific point it may be interesting to read, but more
> interesting will be information which contradicts my general principles.
>
> I don't write well so if I seem to have misstated something please ask
> for clarification.
>
> I think the generally recognized goals of optimization are for speed and
> for space, but as I see it there could be many more goals which may be
> more important then those two. Herein I discuss those which I see as
> being mostly relevant to this forum.
>
> SPEED
Certainly - but spending hours to save a few seconds in a batch that
> I have not studied computer science academically and I have never worked
> in the computer industry so this is merely personal opinion based on 28
> years of programming experience. If anyone has information which
> contradicts any specific point it may be interesting to read, but more
> interesting will be information which contradicts my general principles.
>
> I don't write well so if I seem to have misstated something please ask
> for clarification.
>
> I think the generally recognized goals of optimization are for speed and
> for space, but as I see it there could be many more goals which may be
> more important then those two. Herein I discuss those which I see as
> being mostly relevant to this forum.
>
> SPEED
only gets run once a day is silly.
>
> SPACE
Hmm - like a 128Mb USB, perhaps. Oh, but it has to reside with Uncle
Bill's space-gobblers. Yeah - gotcha.
>
> PROCESSOR USAGE
Nominally, background non-real-time processes should be low-priority and
that's the province of the OS - but we're talking theory aren't we?
>
> MODULARITY
All very good in theory - until the local PhD candidate decides to
optimise your module in some way.
NO on using templates to copy - at least without very strict controls.
I worked for a company where the programmers had become used to using
COBOL copylibs as templates, edited into the programs and altered to
suit. And maintained. And recopied.
Came the inevitable day that the file format changed...
But equally, using copylibs isn't immune to the ministrations of the
ignorant. At another site, copylibs had been used mainly as intended but
the system had been designed by an accountant and implemented by a pair
of programmers who'd had no formal training - in fact, when put on a
formal course had demanded to be removed because it was "braking there
branes."
Came the day when the company wanted to add more branches - implemented
by the inevitable OCCURS clause. The PhD student insisted to her husband
(the "IT manager" who'd simply been a salesman with the company for 40
years) that all that was required was to change the OCCURS clause and
recompile. If I absolutely INSISTED on doing this unnecessary testing,
then she'd get together with her fwend and spend a WHOLE DAY on testing
the 600+ programs in the suite that used the copylib...
'Course - that WAS COBOL, but the principle still applies in my book. A
dose of experience beats all the theory in the world.
>
> READABILITY
Not the most important - THE important matter is that the OBJECTIVE be
achieved. A close second is something you've omitted - RELIABILITY.
Worked for a mob once that was implementing some ISO documentation
standard. The "manager" insisted on using documentation templates such
as "Form 35" (Not "Form 35 - User Requirements.") Everything documented
to the hilt - that the person making the request was authorised, trained
and qualified, as were the analyst and the programmer. Bureaucrat's
paradise. Only thing missing was the certification by the user that all
this uber-documented work actually achieved the objective...
Readability is a sound principle. Naturally, it won't help in the
hopeless cases where OP insists you supply code (for free, of course)
that automatically substitutes their URL and password for 'yoururl' and
'yourpassword' and when it doesn't work, the total response is "It
didn't work properly."
>
> MAINTENANCE
Yes - at least for the literate.
>
> Frank
Dr J R Stockton
Jan 10, 2013, 2:43:37 PM1/10/13
to
In alt.msdos.batch.nt message <op.wqnhd...@anyhost.anywhere>, Wed,
9 Jan 2013 15:30:37, Stanley Daniel de Liver <notag...@invalid.org.in
valid> posted:
>On Wed, 09 Jan 2013 15:16:19 -0000, Frank Westlake
><frank.w...@gmail.com> wrote:
>
>> I have not studied computer science academically and I have never
>>worked in the computer industry so this is merely personal opinion
>>based on 28 years of programming experience. If anyone has
>>information which
>
>Well experience trumps qualifications
>>
>> SPEED
>no! If you need speed, you don't need batch!
Not entirely true. A Batch to do, each time that is run, one single
thing, may not need much speed, especially if it is invoked manually.
But if exhaustive tests are appropriate, as for example in coding a
general Easter Sunday routine, speed may be very useful for the
developer and tester.
Always, in coding anything, aim both for as much speed as is
conveniently possible and also for as much speed as is necessary.
--
(c) John Stockton, nr London UK. Mail, see homepage. DOS 3.3, 6.20; WinXP, 7.
Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
9 Jan 2013 15:30:37, Stanley Daniel de Liver <notag...@invalid.org.in
valid> posted:
>On Wed, 09 Jan 2013 15:16:19 -0000, Frank Westlake
><frank.w...@gmail.com> wrote:
>
>> I have not studied computer science academically and I have never
>>worked in the computer industry so this is merely personal opinion
>>based on 28 years of programming experience. If anyone has
>>information which
>
>Well experience trumps qualifications
>>
>> SPEED
>no! If you need speed, you don't need batch!
thing, may not need much speed, especially if it is invoked manually.
But if exhaustive tests are appropriate, as for example in coding a
general Easter Sunday routine, speed may be very useful for the
developer and tester.
Always, in coding anything, aim both for as much speed as is
conveniently possible and also for as much speed as is necessary.
--
(c) John Stockton, nr London UK. Mail, see homepage. DOS 3.3, 6.20; WinXP, 7.
Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links.
PAS EXE TXT ZIP via <http://www.merlyn.demon.co.uk/programs/00index.htm>
My DOS <http://www.merlyn.demon.co.uk/batfiles.htm> - also batprogs.htm.
Brian Cryer
Jan 11, 2013, 10:34:51 AM1/11/13
to
"Frank Westlake" <frank.w...@gmail.com> wrote in message
news:kck1kb$jec$1...@news.albasani.net...
doesn't matter if one of those cores is maxed out doing something. So whilst
I do agree with you that it isn't desirable to have something long running
that hogs the CPU, on a machine with a dual core or better it is unlikely
that it really matters.
Most of my development is in other languages and I only dabble with batch
files occasionally, and I don't personally recall ever having maxed out the
CPU with a batch file.
Thinking about SPEED & PROCESSOR USAGE, you could perhaps list this under
either of those headings, but the bottle neck in most systems today is I
think the disk drive and not processor speed. So design to minimise disk
reads and writes is desirable.
<snip>
--
Brian Cryer
http://www.cryer.co.uk/brian
news:kck1kb$jec$1...@news.albasani.net...
>I have not studied computer science academically and I have never worked in
>the computer industry so this is merely personal opinion based on 28 years
>of programming experience. If anyone has information which contradicts any
>specific point it may be interesting to read, but more interesting will be
>information which contradicts my general principles.
>
> I don't write well so if I seem to have misstated something please ask for
> clarification.
>
> I think the generally recognized goals of optimization are for speed and
> for space, but as I see it there could be many more goals which may be
> more important then those two. Herein I discuss those which I see as being
> mostly relevant to this forum.
>
> SPEED
> Speed is important if your script needs to do something several times per
> second, or if it is in a sequence of things which must all be done as
> rapidly as possible. But speed optimization is sometimes harmful if it
> unnecessarily hog the CPU.
>
<snip>
>the computer industry so this is merely personal opinion based on 28 years
>of programming experience. If anyone has information which contradicts any
>specific point it may be interesting to read, but more interesting will be
>information which contradicts my general principles.
>
> I don't write well so if I seem to have misstated something please ask for
> clarification.
>
> I think the generally recognized goals of optimization are for speed and
> for space, but as I see it there could be many more goals which may be
> more important then those two. Herein I discuss those which I see as being
> mostly relevant to this forum.
>
> SPEED
> Speed is important if your script needs to do something several times per
> second, or if it is in a sequence of things which must all be done as
> rapidly as possible. But speed optimization is sometimes harmful if it
> unnecessarily hog the CPU.
>
>
> PROCESSOR USAGE
> This is what I think is most often the most valuable optimization. Scripts
> performing maintenance in the background should not hog the CPU. One way
> to optimize for low CPU usage is to have your script sleep occasionally
> for about one second, or once every loop. This makes it easier for the CPU
> to give time to other processes. A script optimized in this way might be a
> very slow script.
Given that most PCs today have at least two cores, quite often it really
> PROCESSOR USAGE
> This is what I think is most often the most valuable optimization. Scripts
> performing maintenance in the background should not hog the CPU. One way
> to optimize for low CPU usage is to have your script sleep occasionally
> for about one second, or once every loop. This makes it easier for the CPU
> to give time to other processes. A script optimized in this way might be a
> very slow script.
doesn't matter if one of those cores is maxed out doing something. So whilst
I do agree with you that it isn't desirable to have something long running
that hogs the CPU, on a machine with a dual core or better it is unlikely
that it really matters.
Most of my development is in other languages and I only dabble with batch
files occasionally, and I don't personally recall ever having maxed out the
CPU with a batch file.
Thinking about SPEED & PROCESSOR USAGE, you could perhaps list this under
either of those headings, but the bottle neck in most systems today is I
think the disk drive and not processor speed. So design to minimise disk
reads and writes is desirable.
<snip>
> My intent here has been to show that speed optimization may be of lower
> importance in many situations and that it is most often going to be of a
> lower importance for scripts in this group.
Agreed. Speed is only important if it isn't fast enough.
> importance in many situations and that it is most often going to be of a
> lower importance for scripts in this group.
--
Brian Cryer
http://www.cryer.co.uk/brian
Frank Westlake
Jan 11, 2013, 11:06:57 AM1/11/13
to
On 2013-01-11 07:34, Brian Cryer wrote:
> Given that most PCs today have at least two cores, quite often it really
> doesn't matter if one of those cores is maxed out doing something.
I guess the purpose of CPU optimization is two-fold:
> Given that most PCs today have at least two cores, quite often it really
> doesn't matter if one of those cores is maxed out doing something.
- Fold one. More efficiently share the CPU. I have a dual core CPU but
I have about 100 processes.
- Fold two. CPU conservation. It is not good to overhead a CPU and an
occasional sleep helps prevent this.
Frank
Frank Westlake
Jan 11, 2013, 11:17:07 AM1/11/13
to
On 2013-01-11 08:06, Frank Westlake wrote:
> - Fold two. CPU conservation. It is not good to overhead a CPU and an
> occasional sleep helps prevent this.
Overhead? Make that "overheat".
> - Fold two. CPU conservation. It is not good to overhead a CPU and an
> occasional sleep helps prevent this.
Frank
0 new messages