Win 64-bit vs. 32-bit client performance

Posted by Marko Myllymäki on 05-Nov-2013 01:44

Now that we have the possibility to use a 64-bit Windows client in 11.3, I wonder if there are any advantages or disadvantages performance-wise when using the 64-bit client. I guess there is no general answer to that, it depends on the application, but are there some specific kinds of uses where the 64-bit client would perform noticeably better or worse than the 32-bit client?

Posted by Libor Laubacher on 05-Nov-2013 09:55

With 64-bit GUI client you can attach directly to a database shared memory when using 64-bit database on Windows. That hasn't been the case before as the GUI client was 32-bit and forced to use Client-server connection to a database. Shared memory database connection is (and I don't want to start a flame here) generally faster than Client-Server. That would be the main performance gain here.

Posted by holzel on 15-Nov-2013 06:58

Matt Gilarde wrote about this topic during the Early Software Access program for 11.3. I quote it here in full:

------

The Early Release of OpenEdge 11.3 on Windows includes a 64-bit GUI client. Most new Windows machines ship with 64-bit operating systems, so it seems to make sense that you would want a 64-bit version of OpenEdge to run on your 64-bit OS. That's not necessarily so. 64-bit versions of Windows can run 32-bit applications. You don't need to update all of your applications to 64-bit versions. So when does it make sense to do so and what are the trade-offs?

The main advantage of running a native 64-bit application is that 64-bit applications can address a lot more memory than 32-bit applications (8TB for a 64-bit application versus a maximum of 4GB for a 32-bit application). That sounds like a great advantage right there. But is it? Most applications don't use enough memory to need the extra address space. If your application never uses more than 500MB of memory it won't benefit from being a 64-bit application. A 32-bit application can easily access 500MB of memory, or even 2GB. Due to the way memory virtualization works, you won't run out of address space even if you run 10 copies of the application. You only run into the need for 64 bits of address space when a single application needs to access several GB of memory. If your application needs to use a lot of memory the 64-bit client will address that need, but you don't need to move to 64 bits just because you're running a 64-bit OS.

64-bit applications are also generally larger than the 32-bit versions. This is because 64-bit applications use 64-bit pointers and those larger pointers take up space. The 64-bit GUI client is about 25% larger than the 32-bit GUI client, mostly due to the larger pointers. This isn't much of a concern since everyone has large hard drives and a couple of megabytes won't be noticed, but it's another of the trade-offs that are made when you move to 64 bits. One thing that doesn't get bigger is the size of your r-code -- r-code compiled in a 32-bit version of OpenEdge is compatible with r-code compiled in a 64-bit version (leaving aside the usual things such as r-code version number changes and GUI/character mode incompatibility).

It is commonly believed that native 64-bit applications are faster than 32-bit applications, but that's not always the case. In fact, some 64-bit applications are slower because data structures tend to be larger in 64-bit applications (again, due to the larger pointers) and moving them around can slow things down. An application that is optimized for 64-bit Windows is likely to be faster than the 32-bit version, but many applications are I/O bound and are unlikely to see any performance gains.

I'm not trying to discourage anyone from using the 64-bit OpenEdge GUI client. I just want to make it clear that you don't +need+ to use it just because your application is running on 64-bit Windows. Moving an application to 64 bits generally requires some development work, which I'll start talking about in another post. Some applications are a good fit for the 64-bit client and we're happy to bring it to you and we'll help you with any issues you run into. On the other hand, some applications won't be a good fit, but fortunately support for the 32-bit client will be around for a long time.

All Replies

Posted by Libor Laubacher on 05-Nov-2013 09:55

With 64-bit GUI client you can attach directly to a database shared memory when using 64-bit database on Windows. That hasn't been the case before as the GUI client was 32-bit and forced to use Client-server connection to a database. Shared memory database connection is (and I don't want to start a flame here) generally faster than Client-Server. That would be the main performance gain here.

Posted by Marko Myllymäki on 08-Nov-2013 02:38

Ok, thanks for the answer, it was helpful. In our case the GUI client and database are usually running on different machines, so I think we'll stick to the 32-bit GUI client if no other reason for using the 64-bit GUI client comes up.

By the way, I agree that the shared memory connection is usually much faster, we use it always when possible (for AppServers running on db server etc.). However, in large installations, you might need multiple server machines for AppServer processes (with load balancing) for performance reasons. And then you lose the benefit from shared memory. That's one reason why I think Progress should develop the database engine so that it could do:

- server-side joins

- database views (or 'ProDatasets defined in database' if you will)

- real db triggers/stored procedures running in db engine

- referential integrity

- etc.

When I have asked for this kind of enhancements I always get the answer: AppServer is the solution. But it is not: when AppServer is running on a separate server, it is just another client using client-server connection.

Sorry for this OT, I just had to get it off my chest... :-)

Posted by Lieven De Foor on 15-Nov-2013 02:09

Hi Marko, you should post your suggestions in the Ideas section (community.progress.com/.../default.aspx). You got my vote!

Posted by Lieven Cardoen on 15-Nov-2013 02:09

+1 for the referential integrity. Still wondering why they won't do that. What's the reason? Is it impossible because of earlier architecture choices?

+1 for the AppServer is NOT the solution.

Posted by holzel on 15-Nov-2013 06:55

Referential Integrity is "on the list" and is in our product backlog but just hasn't yet been able to rise to the top of the list. I have never heard that it would be impossible due to how the OE DB is architected. As usual, it is mainly a matter of available resources.

Regards

Rob

Posted by holzel on 15-Nov-2013 06:58

Matt Gilarde wrote about this topic during the Early Software Access program for 11.3. I quote it here in full:

------

The Early Release of OpenEdge 11.3 on Windows includes a 64-bit GUI client. Most new Windows machines ship with 64-bit operating systems, so it seems to make sense that you would want a 64-bit version of OpenEdge to run on your 64-bit OS. That's not necessarily so. 64-bit versions of Windows can run 32-bit applications. You don't need to update all of your applications to 64-bit versions. So when does it make sense to do so and what are the trade-offs?

The main advantage of running a native 64-bit application is that 64-bit applications can address a lot more memory than 32-bit applications (8TB for a 64-bit application versus a maximum of 4GB for a 32-bit application). That sounds like a great advantage right there. But is it? Most applications don't use enough memory to need the extra address space. If your application never uses more than 500MB of memory it won't benefit from being a 64-bit application. A 32-bit application can easily access 500MB of memory, or even 2GB. Due to the way memory virtualization works, you won't run out of address space even if you run 10 copies of the application. You only run into the need for 64 bits of address space when a single application needs to access several GB of memory. If your application needs to use a lot of memory the 64-bit client will address that need, but you don't need to move to 64 bits just because you're running a 64-bit OS.

64-bit applications are also generally larger than the 32-bit versions. This is because 64-bit applications use 64-bit pointers and those larger pointers take up space. The 64-bit GUI client is about 25% larger than the 32-bit GUI client, mostly due to the larger pointers. This isn't much of a concern since everyone has large hard drives and a couple of megabytes won't be noticed, but it's another of the trade-offs that are made when you move to 64 bits. One thing that doesn't get bigger is the size of your r-code -- r-code compiled in a 32-bit version of OpenEdge is compatible with r-code compiled in a 64-bit version (leaving aside the usual things such as r-code version number changes and GUI/character mode incompatibility).

It is commonly believed that native 64-bit applications are faster than 32-bit applications, but that's not always the case. In fact, some 64-bit applications are slower because data structures tend to be larger in 64-bit applications (again, due to the larger pointers) and moving them around can slow things down. An application that is optimized for 64-bit Windows is likely to be faster than the 32-bit version, but many applications are I/O bound and are unlikely to see any performance gains.

I'm not trying to discourage anyone from using the 64-bit OpenEdge GUI client. I just want to make it clear that you don't +need+ to use it just because your application is running on 64-bit Windows. Moving an application to 64 bits generally requires some development work, which I'll start talking about in another post. Some applications are a good fit for the 64-bit client and we're happy to bring it to you and we'll help you with any issues you run into. On the other hand, some applications won't be a good fit, but fortunately support for the 32-bit client will be around for a long time.

Posted by Thomas Mercer-Hursh on 15-Nov-2013 09:06

If by referential integrity you mean having a join table in the database, that is a long running irritation to people who want to build ERD diagrams, but I question what else it impacts.  There is nothing to constrain one from making a join which is not defined nor from building a query which follows a defined join, but does so in a way which is inefficient.  So, I wonder what impact it really has beyond easily built ERDs (which may be lying since they don't represent actual use).  A tool like ABL2UML shows actual use ... which seems more important to me.

This thread is closed