Attached patch moves uuid import from inside try-except
to register_uuid function. Reason: uuid module import is *very*
heavy. It goes into OS searching for various .dll/.so libraries,
lauches 'ldconfig' and so on...
With this patch, 200x python -c 'import psycopg2.extras'
goes from 22s to 7s. (plain 'import psycopg2' is 6s)
--
marko
In fact it doesn't change "the transaction", as there has to be no
transaction when invoked. The effect instead is to execute SET SESSION
CHARACTERISTICS.
Python versions 2.4 and 2.5 for MSVC on Windows do not need to manifest file
reinserted into the DLL. The VC compiler for these versions does not have the
mt.exe executable to insert the manifest file.
At init time, build_ext is not configured, so neither the --compiler option
nor settings in setup.cfg/distutil.cfg is effective.
Steve, I told you distutils was a mess :)
- Make sure to declare self.pg_config in initialize_options.
- Don't declare PostgresConfig in __init__, as its scope is limited.
- Pass build_ext instance to PostgresConfig to avoid having to
call the option parser directly.
- Don't override global variable name "ext" (use "extension" as function
argument names)
- Improve function naming (get_compiler -> get_compiler_name)
- Other misc operator spacing and 80-column violation cleanup.
- Remove unneeded import (DistUtilsFileError)
The MSVC compiler does not have the strcasecmp(x, y) function, which is a
case insensitve string compare function. Instead, MSVC has a similar function,
lstrcmpi(x, y). Modified config.h to use this function when building with
MSVC.
Functions conn_setup(), conn_get_isolation_level(), conn_set_transaction(),
conn_switch_isolation_level(), conn_set_client_encoding() reimplemented
using the pqpath funtitons.
Dropped analogous function in the connection, as it had to take the lock,
thus it was hard to build consistent pieces of functionality with it.
The aim of these function is to allow the connection to make a better use
of the pqpath functions instead of using PQexec for these small things.
Also, the functions are to be called with the connection lock: this makes
composing higher level functions using them easier.
The function is always called in the context of functions grabbing the
connection lock, so just use the same critical section instead of releasing
and re-acquiring it. It is not a problem as serious as the notifies process
(ticket #55) as the notices are a psycopg structure, not libpq. However the
change allows again processing notices/notifies in the same place,
which makes sense conceptually, plus we save some lock dance.
Notifies process access the connection, is not limited to the result, so
There is the possibility of loss of protocol sync in multithread programs.
Closes ticket #55.
