Most our software has 64-bit releases as well as old-style 32 bit builds. Let us describe reasons to use them, possible limitations and a few practices.
Advantages
All modern Windows operations systems are 64 bit. That means any 64-bit application is native when 32-bit one uses some adapter also known as "Windows on Windows". Actually, typical 64-bit application can work a little bit faster than 32 bit. In our tests, the difference never exceeds 3-4%.
However, there is the case with a really great performance increase of switching to the 64-bit system. It is large memory usage. If the job requires more than 2 Gb of working sets, the software can't store them in RAM directly. We have to use the extra disk to RAM transfers. Of course, these transfers are very slow. We'll describe examples in the "Cases" section of this article.
The second advantage is "native" connections to database servers. If you have 64-bit client software for your database 64-bit tool allows you to avoid conversions for 32-bit API calls. It can add a few percents to the software performance.
Limitations
The most important problem is old ODBC drivers and OLE DB providers. If you have some legacy system created 10+ years ago it is possible that 64-bit drivers do not exist at all. 64-bit drivers compatibility for old systems is also a problem. Some drivers provide less service level than 32 edition.
The required driver availability is the second inconvenience. Any Windows operating system after the 2000 year provides users with 32-bit drivers for Excel, Access, DBF, etc formats. However, Windows 7, 8 and 10 have no mentioned 64-bit drivers in the installation package. The user has to find, download and install the drivers manually if necessary to access the document by legacy MS Office's product (.mdb or .xls) from 64-bit code.
64-bit code requires more memory itself. It is not a problem if your system has 16+ Gb RAM but it is important if you have 4 or 6 Gb only. Any memory pointer in 64-bit code requires 8 bytes whereas 32 pointer has 4 bytes length only.
Cases
In this section, we'll provide 3 examples of 64 build versions wins. Most of them are about the performance of test data generation.
The first case dwells with the unicity check. If you check on 3 columns of tables to be populated by "Unique" flag the data generation software have to keep in the RAM some validation value for each generated item. At the moment each validation value requires 4 bytes. Actually, it is the CRC32 checksum. In other words, you need 3 columns * 4 bytes * the number of rows memory for this unicity-check utility. For 150-160 million rows it requires all available memory for the single 32-bit application.
On the other hand, if you have 16 Gb RAM and the 64-bit version of the data generator, you can create 1 billion rows without any performance degradation.
The second case is about large external data sources: files, database tables, etc. By performance reason, the data generator preloads the data array to memory and takes individual data item at the execution step without external requests. However, it requires a lot of memory. If you have a table with 10 million unique string values and n eed to use it as a source, you have to use 10 million * average string length RAM. If you have 2 sources like mentioned with 50 characters per value, 32-bit software does not allow you to do that directly (1 Unicode character requires 2 bytes in UTF16 encoding).
The last case describes transaction size for extra-wide tables. Some databases performance depends on transaction size. If you generate a lot of test data, increasing transaction size from 100 to 50,000 rows per transaction can increase performance to 10 times and more. But if your table has 500 columns with the average length of the column 80 bytes the 50K batch of rows exceeds the available RAM. In this case, you have to decrease batch site or to switch to the 64-bit version of the tool.
As a summary we recommend to use 64-bit versions of our tool if you have:
- at least 8 Gb of RAM in your PC
- all required connectivity components (drivers providers or native clients)