Hi, Dne 11.7.2017 v 22:37 at2tce3bx6dxq2hngnxe5xv74qhlsmeghchit...@yahoo.com [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