Just had an upgrade of a small scale system that uses an ISAM database (indexed sequential access method) (not my choice!!)and was 16 bit but now is 32 bit.

Question is....
...how will the processes be different in a tecnospeak way ?
ie, will 32 bit use more CPU, RAM etc for processing the same volume of data, or will it use less CPU & RAM.

Is there a minimum spec needed for running 32 bit,
would 64mb of RAM with 300mhz cpu speed be too slow ??

 

I assume it's an old application written for DOS/WIN16.

A 32-bit program will use the Win32 library, which in turn makes better use of the resources available especially on anything above a 386.

16 bit programs run like a dog on anything with an NT kernel, so moving to 32 bit will give you a hell of a performance increase on WinNT, Win2K, WinXP,...

Fundamentally, the difference between a 16 bit and 32 bit system is that the 32 bit system can shift twice as much data for every processor cycle. Things have advanced a bit since that statement was strictly true, so you should see a performance increase in your application. The OS makes a lot of difference too.

 

I think using 32-bit will also mean the database has more addressable memory to work in so more data will be stored in RAM as your pointers have a larger address range (2^32 bits rather than 2^16 bits). Net result is better performance and more efficient use of resources as Chiark says.

I don't think there are minimum requirements for running "32-bit" - it's a bit like saying how much petrol do I need to drive fast . As was said above, requirements will likely be down to the OS itself and remember that everything from the 386 is 32-bit (in hardware anyway), so as long as you're running 32-bit software, you'll be fine.

Chris

 

Thanks for the replys..

Food for thought.

Our new 32 bit processing now means that a certain process takes 3 hours rather than 5 mins as it did on the 16 bit version.
Our software has been customised (some one used the word "butchered") and that may be the problem.
ie non standard software.

Another potential problem may be "oppotunistic locks" on the database. Basically, the database would be locked to users, the processing would happen, then the database would be unlocked again, for the same process to happen again for record number 2 etc. Only 15,000 entries to process this week. I guess if this does happen, it would only treble the processing time, as 3 processes take place instead of 1 ??
5 min --> 3 hrs is quite an increase though, definately not x3 !!

 

aaah, the joys of progress. 5 mins to 3 hours.

Would guess it's a locking issue, or possibly someone deciding to replace SQL queries with their own "special" coding to do something...