VisualWorks
WebVelocity
Here's a weird one for ya:
We're running some speed trials on different databases and we've got Oracle 10, Postgresql, SQL Server and Sybase. All was going well, we were using the native drives in VW for Oracle and Postgres and ODBC drivers for Sql Server and Sybase.
Then the weirdness struck. We realised the #execute statement in Postgres was not creating a cursor, it was actually reading all the results in to memory and then giving a Smalltalk stream back on the array! Good god.
So, we were suddenly forced to use the odbc driver for postgres to get proper streaming. This is when we made an amazing discovery. The ODBC driver for Oracle and Postgres were faster than the native drivers.
By native I mean the Smalltalk implementation talking to the native dll's for the database.
Here are the timings off our crap network to our crap database server.
Native Oracle: 2.5s to retrieve 10,000 records
ODBC Oracle: 0.7s to retrieve 10,000 records
ODBC Postgres: 0.5s to retrieve 10,000 records
Wowee.. what's going on here? Are the native drivers written badly in Smalltalk and the ODBC driver written really well or what?
By Terry on July 27, 2006, 7:35:05 amComment by Terry
Michael
Try changing your block factor to a larger number.
By Troy Brumley on July 27, 2006, 12:09:52 pmComment by Troy Brumley
ODBC drivers seemed to consistently outperform native drivers on Windows in something I was working on a couple of years ago. I think it's a matter of familiarity and coding one towards the other.
By Michael Lucas-Smith on July 27, 2006, 7:35:10 pmThanks Terry, the blockFactor made a huge difference. Although the postgres driver still insists on reading everything in to memory. At least we'll be able to use the native oracle driver cross platform now :) I'd say the ODBC driver is setting up the blockFactor as a default and that's why it gave us an initial speed boost. Oracle native is about 2.5x faster then the ODBC now.
By on July 31, 2006, 9:55:23 amx5 times faster than ODBC