On 5/3/2016 2:41 PM, Tim Chase wrote:
On 2016-05-03 13:00, DFS wrote:
On 5/3/2016 11:28 AM, Tim Chase wrote:
On 2016-05-03 00:24, DFS wrote:
One small comparison I was able to make was VBA vs python/pyodbc
to summarize an Access database. Not quite a fair test, but
interesting nonetheless.
Access 2003 file
Access 2003 VBA code
Time: 0.18 seconds
same Access 2003 file
32-bit python 2.7.11 + 32-bit pyodbc 3.0.6
Time: 0.49 seconds
Curious whether you're forcing Access VBA to talk over ODBC or
whether Access is using native access/file-handling (and thus
bypassing the ODBC overhead)?
The latter, which is why I said "not quite a fair test".
Can you try the same tests, getting Access/VBA to use ODBC instead to
see how much overhead ODBC entails?
-tkc
Done.
I dropped a few extraneous tables from the database (was 114 tables):
Access 2003 .mdb file
2,009,164 rows
97 tables (max row = 600288)
725 columns
text: 389
boolean: 4
numeric: 261
date-time: 69
binary: 2
264 indexes (25 foreign keys)*
299,167,744 bytes on disk
1. DAO
Time: 0.15 seconds
2. ADODB, Access ODBC driver, OpenSchema method**
Time: 0.26 seconds
3. python, pyodbc, Access ODBC driver
Time: 0.42 seconds
* despite being written by Microsoft, the Access ODBC driver doesn't
support the ODBC SQLForeignKeys function, so the python code doesn't
show a count of foreign keys
** the Access ODBC driver doesn't support the adSchemaIndexes or
adSchemaForeignKeys query types, so I used DAO code to count
indexes and foreign keys.
--
https://mail.python.org/mailman/listinfo/python-list
