Hi,

Dne 11.7.2017 v 22:37 at2tce3bx6dxq2hngnxe5xv74qhlsmeghchit7zi@...
[firebird-python] napsal(a):

>
> I was not using a prepared statement -- I think I was looking at the 0.9.9 docs on firebirdsql.org and I missed that it no longer creates them. (To which I'll add: it would be nice if it behaved the same as kinterbasdb [where a cursor prepares/caches only the current statement] so it is a drop in replacement. But if that's non standard behavior, I understand).

It's not standard, just an enhancement that kinterbasdb did for
convenience and that was adopted by FDB (to maintain compatilbility).
However it introduces internal problems as well. It's not easy to manage
number and lifetime of internally cached prepared statements, which is
critical as they consume Firebird server resources. Due to reoccurring
problems with that I eventually decided to drop this feature. I guess
it's easier to notice performance drop and fix that with explicit use of
prepared statement (which is recommended practice in general) than
notice resource exhaustion (due to careless use of this feature) that
can eventually lead to server failure.

> Using a prepared statement definitely helps -- it's over twice as fast. However kinterbasdb is still about 50-150% faster. My simple table is at the 150% end, and consists of an integer pk and 3 varchars with the same 3 strings every insert. I'm not sure if that helps at all -- is there anything we can do?

Well, kinterbasedb is mostly written in C/C++ while FDB is pure Python
using ctypes to call FB API. So FDB will always be slower than KDB
especially in huge loops like mass inserts. It may be optimized using
compiled/jit python code (PyPy or IronPython should be able to do that)
but I never tested it.

For time critical jobs it could be better to use something else than
Python, like FreePascal/Lazarus with IBX (https://www.mwasoftware.co.uk/ibx)

best regards
Pavel Cisar
IBPhoenix