Thin vs Thick Performance Implications

[mkmoisen]

Hi @anthony-tuininga

Is there any performance implications by using the thin style instead of the thick style?

Assuming there is no performance implications, and I don't use any of the features that require the thick style, are there any other draw backs to converting my application to the thin style?

Most importantly, why did you change the name from cx_Oracle? I've been using it a long time, it will be an adjustment to remember to import oracledb going forward :).

[cjbj]

You should do your own benchmarking (and let us know what you find). The numbers we see for the Thin mode are great - see the release announcement for some data. But there are different implementations of functionality compared with the Oracle Client libraries, and there is a different interplay with Python's GIL, so you might seen somethings better, and others different.

If you don't want Thick features, there are no particular drawbacks to only using Thin mode.

The name change was overdue. The mix of snake & camel-cases was a pain. Although unique, it didn't reflect what the driver did. The use of 'cx' in Oracle-land leads you to https://www.oracle.com/cx/ (which has nothing to do with cx_Oracle). The new name also aligns with the Node.js node-oracledb driver.

[mkmoisen]

Thanks. Would you be able to elaborate a bit on how thin mode utilizes the GIL differently than thick mode? I might have missed it, but didn't see any reference to this in the docs.

[anthony-tuininga]

The difference lies primarly in how much code is executed while holding or not holding the GIL. The thick driver makes use of ODPI-C, which allows for more processing to occur while the GIL is not held. The thin driver only releases the GIL when performing I/O. This means that depending on your workload you may see different performance characteristics between thick and thin. For most this is an internal implementation matter, but Chris mentioned it because someone might ask why things are different! I did a quick search and it isn't found in our documentation. Perhaps it could be added to Appendix B? Let's see what Chris thinks.

[anthony-tuininga]

Hi, @mkmoisen, Chris beat me to it. :-) As Chris mentioned, it very much depends on what data you are fetching/inserting/updating in your scenarios. One of the significant benefits of the thin driver is the reduced memory and CPU usage -- mostly due to the fact that the thin driver has direct access to the network buffers, thereby eliminating a copy and conversion step that the thick driver has to take. This frequently translates to a noticeable difference in performance. Please do let us know what you find!