Hints for Faster Computing!

updated 2/21/2017. Most but not all material that is specific (or largely specific) to 2005 and older machines and versions of Windows has been moved to here.

General computer speedup hints:
Your computer may be slowed by insufficient memory
Possible disappointments of more-modern processors or operating systems
Registry Cleaning - and what I like!
Multiple hard drives? A booting speed tweek!
Some manual registry editing tweeks!
Two fixes for Firefox drive churning
Editing the Windows Hosts file to block website ads and data mining
The AGP memory thief, and how to reduce

Programming speedup hints: (Some largely specific to old DOS programming languages):
A couple Programming Tips, especially for math-intensive loops
A couple extra tips for Microsoft Basic programs such as mathptch.obj
(a minor correction 8/17/99)
C Vs. Basic and a few Microsoft Quick C tips
A couple precision and floating point tricks!

Your computer may be slowed by insufficient memory

If your computer is often slow and your hard drive is being used a lot, the most common reason is insufficient memory. A machine running on Windows XP "Home Edition", *not* being used for "power computing", typically requires 256 meg (1/4 gig) of RAM to run smoothly. Higher versions of Windows and "power computing" will typically make the memory requirement even higher.

As of late 2012, computers that were "fairly baseline" had 1 gig of RAM.

If you upgrade the RAM yourself: Please check your motherboard manual for requirements, if you can. Also, it's a good idea to get your RAM from a place that knows the requirements and limits of your motherboard and your processor. There may be requirements or restrictions on the number of pieces ("sticks") of RAM to use, a limit on how much RAM to use, a requirement for multiple sticks to match, and limits by your motherboard for how much per-stick and total RAM can be used. Also, your operating system may have a RAM limit.

Possible disappointments of more-modern processors or operating systems

Sadly, processor core speed has less than doubled since 2005.

Upgrading to a 64-bit or multiple-core processor or an operating system designed for such a processor can have some disappointments:

1) A 64-bit or multi-core processor largely requires an operating system designed to take advantage of such.

2) Software not designed for a 64-bit processor will generally not run faster by upgrading to a 64-bit processor. (Exception - some math-intensive or video-intensive applications *may* run faster on more modern processors - but don't bet the ranch on that.)

3) It's a tall order to get 16-bit software to run under a 64-bit operating system. Most software that can run under DOS or Windows 3.1 is 16-bit. For a 64-bit version of Windows to run 16-bit software, typically the user has to get the "Professional" version of a 64-bit version of Windows. And "Pro version" is typically not sufficient alone - but necessary to use an add-on that is necessary, and which typically has further additional cost.

4) Newer processors are largely optimized for newer software. Older software that can run on a single-core 32-bit processor, especially legacy-old 16-bit software, may be *slowed* by changing to a more modern processor.

Registry Cleaning - and what I like!

There is such a thing as reasonably safe and reasonably effective registry cleaning. And, I have found that necessary for a Windows machine to run more smoothly, especially for reducing time needed to boot. This is especially true if you have uninstalled or multiply-upgraded software.

My favorite registry cleaner is Registry First Aid. It is not free, but it is inexpensive.

Two things I like about it:
1) It is effective. 2) It "plays safe", and gives options for users to manually take more aggressive actions on specific registry keys where doing anything is riskier.

One quirk: If Registry First Aid finds 1,000 or more items to take action on, it wants to do only a thousand at a time. You may have to run it more than once, especially if for the 1st time, or after a major software uninstall.

Multiple hard drives? A booting speed tweek!

Does your computer have more than one hard drive? Or a hard drive and an optical drive on the same channel?

If so, then mixing/mismatching can slow early stages of booting. I have found that it helps (on my favorite machine) to have any multiple hard drives to all be by the same manufacturer.

Also, I like to not have both a hard drive and an optical drive on the same channel. For example, if you use an IDE hard drive, put it on the first IDE channel (IDE 0), and your optical drive on the second IDE channel (IDE 1).

A couple manual registry editing tweeks!

There are 3 things that are good to do, in terms of minor registry cleaning.

These are only 3 simple things that I tried, with good results. And, the web recommends these. Please BE NOT AFRAID to venture into the scary "under the hood", for stuff as simple as checking an oil dipstick ... Or maybe, at-worst, comparable to replacing a belt. This is tried-and-true stuff, and I learned these from the Web. This is not as adventurous as at-home auto repair, beyond doing an oil change and replacing the oil filter.

I suggest two simple items.

1) The first is deleting at most 4 subkeys that slow access of optical drives, and sometimes causes them to malfunction. I suspect this *may be* malware, or a gateway for malware. (NOTE - This is my personal suspicion, based on my personal experiences, and I *disclaim* that this is a statement of fact.) This may be a CD drive bug or "bugware" issue. It may come from a mere poorly-designed software installation package.

How to remove:

This involves using the Windows registry editor. Click "Start", "Run", and type-in "regedit" (without the quotes). (It is advisable to use that program's function for backing up the registry 1st, in case you screw things up.)

Click the "+" of HKEY_LOCAL_MACHINE.

Click the "+" of SYSTEM.

Click the "+" of CurrentControlSet. (And repeat everything below for ControlSet001 and ControlSet002.)

Click the "+" of Control.

Click Class.

Click {4D36E965-E325-11CE-BFC1-08002BE10318}.

Verify that on the right hand side of the screen, two items:

One line has name being (Default), "data" being DVD/CD-ROM...

Another line has name being Class, "data" being CDROM.

If you get that far, look for lines whose data (or type) are upperfilters or lowerfilters. Right-click each of any such lines (in the right pane of the screen) with upperfilters or lowerfilters, then proceed with deletion.

Repeat for {4D36E967-E325-11CE-BFC1-08002BE10318}.

After that, close regedit and then flush the recycle bin.

2) Do this - citeable by this PC World article on 6 registry hacks to speed things up.

a)): Open the Registry Editor and go to HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > ContentIndex. (And for everything you do in CurrentControlSet, repeat in ControlSet001 and ControlSet 002.)

b)): In the right pane will be a value called "StartupDelay." Double-click on StartupDelay to open it. Change the "Base" from Hexadecimal to Decimal, and enter 40,000 (the default setting is 480,000).

In my personal experience, this works better when "drive agreement", as mentioned above, is optimized.

3) Do a web search for how to edit the registry to speed up Disk Cleanup by disabling its option to Compress Old Files.

In Windows XP: Use Regedit and go to: HKey Local Machine > Software > Microsoft > Windows > Current Version > Explorer > Volume Caches > Compress Old Files

Next, double click on the REG_SZ (default) variable to edit it, and delete B50F5260-0C21-11D2-AB56-00A0C9082678

This is from this UCLA knowledge base article.

Two fixes for Firefox drive churning

One trick is to go to Bookmarks, Bookmarks Toolbar, and delete Latest Headlines. Reference here.

Another trick is to type about.config into the web address bar and scroll down to the item browser.sessionstore.interval, and increase its value from 15000 (15 seconds) to something greater such as 900000 (15 minutes). This reduces frequency at which Firefox backs up a loaded web page for recovering from a crash.

For a more extreme fix, sessionstore can be disabled by changing these five items:

browser.sessionstore.max_resumed_crashes   from    1 to 0
browser.sessionstore.max_tabs_undo         from   10 to 0
browser.sessionstore.max_windows_undo      from    3 to 0
browser.sessionstore.restore_on_demand     from true to false
browser.sessionstore.resume_from_crash     from true to false

Editing the Windows Hosts file to block ads and data mining

If you use Windows, do a web search for how to edit the hosts file to block specific websites, such as ones that many other websites use for ad content and feeding you cookies including 3rd party ones.

In Windows XP, use Windows Explorer and go to: My Computer > Local Disk (C:) (or whatever your boot drive is) > Windows > System32 > Drivers > etc by clicking the appropriate + symbol each step of the way, and then find the file hosts. Double-click that file to open it. You will be prompted to select a program to use - use Notepad. (This is not the only way to do this.)

You can edit this file. You can save the original under a different name such as hosts.org or hosts.bak or hosts.bku or the like. The working copy must be named hosts without an extension.

To block a website: Add a line such as these:

127.0.0.1 adclick.g.doubleclick.net
127.0.0.1 vsrv.tlvmedia.com

Add a similar line for each advertising or data mining site that you identify and want to block. What usage of 127.0.0.1 in this file does is causing your Internet software to look at the web server in your own machine for these sites, where they don't exist. You probably don't have a web server in the machine you use for viewing web sites anyway.

In my experience, tlvmedia causes serious bugginess in at least one website, likely because I use an older version of Windows. Blocking identifiable 3rd party sites that give appearance of advertising or data mining for advertising can make your web experience faster at some websites, and reduce the number of cookies fed to you. I have known an antispyware program to have identified some cookies from doubleclick as lowest threat spyware and worthy of deletion by that program.

Please note that some websites have functionality reduced depending on what you block. Blocking websites whose names include the name of a major search engine or the domain of a major map service site may impair functionality of websites using these and possibly your usage of such a mapping service site.

The AGP memory thief, and how to reduce

Some computers with motherboards supporting AGP video have some of their RAM reserved for video use and unavailable for the purposes for which the RAM is usually used. This is true even if you use a PCI (or other non-AGP) video card. You can usually reduce but not eliminate this memory theft.

When the computer is in an early stage of booting up, there is usually a message, "hit DEL for setup" or something to this effect. You may need to hit "Del" as soon as this message appears in some computers. This gets you into what they call "CMOS Settings". One of the "groups" other than "Standard", "Optimal", "Power Management" and "Save" may have an option of amount of memory to be used for AGP purposes. Reduce this quantity to the smallest amount that will serve your needs.
As for how much? If your video is not AGP, select the minimum - in my experience, this is not zero. If you have AGP video, what you need will probably be typically 4 times the maximum number of pixels used in your display, maybe a bit more, maybe double that, maybe double again for playing movies or video games. Select the smallest amount that matches or exceeds your need.
After adjusting this, back up (usually "Esc") to the CMOS main menu, then select Save Changes and Quit. Booting will resume.

A couple Programming Tips, especially for math-intensive loops

1. Get any calculation involving constants out of the loop. For example,
you might have:

a=i*(b+3) in the loop.

If b is the same everytime you go through the loop, then before the loop have a line as such:

b3=b+3 before the loop and
a=i*b3 in the loop.

Another example: If you have x squared more than once in the loop and x does not change during a pass through the loop, then have a line before the loop as such:

x2=x*x

and refer to x2 instead of squaring x all over again.

2. You should know that power functions are quite time consuming. How this is usually actually done is by taking a natural log, multiplying the log by the power, then taking the natural antilog. To make things work faster, instead of saying y=x^2 say y=x*x. You can do cubes faster by saying y=x*x*x than by saying y=x^3. And an SQR takes less time than raising something to the .5 power. You can square root something twice faster than raising something to the .25 power.

As for raising something to the fifth power? The fastest way is usually to do:

xx=x*x
y=xx*xx*x

A couple extra tips for Microsoft Basic programs

There is a bug with the coprocessor-compatible floating point math in executables produced by most Microsoft basic compilers such as Quick Basic 4.5 and Basic 7.1 ("QBX"). The math processing takes 2-4 times as long as it should even when everything is going right.

If EMM386.EXE (typically used with Windows 3.1 and DOS 5 or 6) is loaded, the speed is 1/3 to 1/5 the already-slow value. With Windows 3.1 running, an additional slowdown almost as bad as that of EMM386.EXE occurs. Quarterdeck's QEMM386 is not as bad as EMM386.EXE, causing an additional slowdown of only a few percent.

There is a solution. Dan Barclay (dbarclay@ih2000.net) has published a patch. The patch nearly enough restores full speed of math coprocessor usage and eliminates about 99.5 percent of the Windows 3.1 and EMM386.EXE slowdowns of math coprocessor usage.

One way to use this patch in Quick Basic 4.5 if your program has only one module: Add a line at the beginning of the program:

call PatchINT3D

Then save the program and quit Quick Basic and return to a DOS prompt. At the DOS prompt, BC foo (where foo is the name of the basic file. Omit the .BAS extension.).
When compiling is complete, link as follows:

link foo.obj mathptch.obj, foo.exe, nul.map, bcom45.lib

Or, for a smaller executable file size, do this:

link foo.obj mathptch.obj smallerr.obj, foo.exe, nul.map, bcom45.lib /e /noe

(the command line may wrap around as you type it - this is OK)

Here is a more proper way to use the patch:

At a DOS prompt, get into whatever directory the library files are. In Quick Basic 4.5, this is usually the \qb45 directory. In Basic Compiler 7 ("QBX"), this is usually \bc7\lib.

Then type lib and enter.
Lib will prompt for a name for a new library. Enter a name matching no other library files. Lib will then prompt for creating - answer Y.
Lib will prompt for operations. Enter +mathptch.obj. Lib will prompt for a list file. Enter nul.lst. After all this, you have a new lib file which must be converted to a qlb file by link.

For Quick Basic 4.5, do this, where "foo" refers to the library name without the lib extension:

link /q foo.lib, foo.qlb, nul.map, bqlb45.lib

and hit enter.

For Basic Compiler 7 ("QBX"), only the last library name is different:

link /q foo.lib, foo.qlb, nul.map, qbxqlb.lib

You now have the quick library. To use it, at a DOS prompt type qb /lfoo or qbx /lfoo and then enter. Load the BASIC program, and type into the beginning of the BASIC program the line:

call PatchINT3D

You can then alt-r-x for "make .EXE". This also improves the speed of Quick Basic running the uncompiled BASIC code, but it will be so much faster as an .EXE.

This patch also supposedly works in at least some versions of Visual Basic. There is hope that it may also work with some versions of Microsoft C, although I just tried a bit with Microsoft's Quick C 2.5 and that did not seem to need mathptch.obj to get optimized-looking speed.

As for where to get the patch? You can download a ZIP file (mathptch.zip) containing the patch (mathptch.obj), assembly source code and some usage documentation by its authors (read.me and mathptch.asm), and the above usage documentation by me (usage.txt) by clicking here.

Something else: BC7 has an option for faster executable code requiring at least a 286 processor. If you don't fix the math coprocessor slowdown, it is 10 to 40 percent less severe with 286 code than without. I am sure other things also run faster with 286 code, but I have yet to investigate this. If you use mathptch.obj, 286 code makes little difference in math coprocessor speed (generally less than 5 percent) - at least on a Pentium II.

C Vs. Basic and a couple Microsoft Quick C tips

I finally translated my personal benchmark program from Basic to C. This thing uses lines from an actual engineering application I wrote and mostly does addition, subtraction, multiplication and division.

Results when compiled by Microsoft Quick C 2.5 - slightly faster than with Microsoft Quick Basic 4.5 or Basic Compiler 7 (about 12 percent less running time for my test program). And I did not need mathptch.obj. Those not using mathptch.obj will often find C much faster than Basic, by a factor of at least 2 and sometimes in excess of 10.

Now for optimizations for Microsoft Quick C:

With Quick C running, do an alt-O for Options and then M for Make options. First, I use Release as opposed to Debug. Then there are the compiler options. I use the Medium memory model when it works which is probably close enough to 99 percent of the time. As for Release Optimization options - I used Full as opposed to On or Off.

If alt-O only gives two options including Full Menus, turn on Full Menus and try again.

Link options did not seem to do much.

Now for a bit of bugginess: The size of the name of the .EXE affects how fast my personal test program runs. With the memory model being Medium, it works faster if the name of the .EXE is two letters or less followed by .EXE and slower with longer names. The reverse occurred with Small and Compact memory model size. This may be obscure Microsoft bugs triggered by some unusual combination of aspects of the code including approaching a limit on stack utilization or string space or something like this - I have seen strange things of this sort occur before with Microsoft programming languages! Or I could be just about using all memory locations in the L1 cache and minor changes could be having random effects on L1 cache caching all looped code and data. Exe-file-name-size-dependent results were duplicated on an Intel 400 MHz P2 and an AMD 1.33 GHz K7 TB processor.
Generally, I would use the smallest memory model that works, except I have some experience that Small is sometimes better than Compact when both work. And if the executable is produced by a Microsoft compiler that runs under DOS, try renaming the .EXE to various name lengths plus the .EXE extension. 1, 2, or 6 letters followed by .EXE have a chance of being "magic" faster-running names but try all eight possibilities of name length!

A couple precision and floating point tricks!

Double precision vs. single precision - in my experience, double is not much slower. My guess is that the processes used are double precision compatible even when reading and writing single precision variables.

But there is a trick in Microsoft Quick C and probably most other C compilers for x86 types: In Microsoft products, at least Quick C 2.5, it is called _control87. This affects the precision of the math coprocessor in x86 machines having one (Includes 486DX and higher - the math coprocessor is an add-in option for lower machines.) There are three options for _control87 - 64 bit (default), 53 bit, and 24 bit.

53 bit will compromise double precision, and 24 bit will compromise single precision and make double precision largely useless. But 24 bit precision is good enough for most single precision applications.

As for speed using my personal test program, which does a lot of adding, subtracting, multiplying and dividing and some comparisons but not much else:

53 bit takes about 10 percent less time than 64 bit on an Intel 400 MHz P4, although only .5% less time than 64 bit on an AMD 1.33 GHz TB.
24 bit takes about 32 percent less time than 64 bit (I only tested on Intel 400 MHz PII so far).
64 bit takes about 7 percent more time using double precision variables than with single precision variables - I only tested on 400 MHz Intel PII so far.

Written by Don Klipstein.

Please read my Copyright and authorship info.
Please read my Disclaimer.