You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was trying to optimize the performance of a multi-threaded code in which multiple threads could execute Jx9 code against the same database. Unqlite is compiled with multithreading support. I noticed that unqlite locks the database's mutex while compiling the Jx9 code, here:
SyMutexEnter(sUnqlMPGlobal.pMutexMethods, pDb->pMutex); /* NO-OP if sUnqlMPGlobal.nThreadingLevel != UNQLITE_THREAD_LEVEL_MULTI */
This prevents multiple threads from compiling VMs in parallel. Whether VMs can execute in parallel is another story, but I was at least expecting to be able to compile Jx9 programs concurrently, in particular because timing information shows that this compilation is what takes up most of the time in my scenario. Is there a reason for this part of the code to be serial?
The text was updated successfully, but these errors were encountered:
The reason access is serialized when compiling different Jx9 scripts within a same UnQLite database engine is simple: A same UnQLite DB hold a single Jx9 handle (compiler) which cannot compile scripts in parallel and thus access is serialized.
This should not be a major issue if you factor your code intelligently (eg: compile your Jx9 scripts, and cache the resulting VMs at program start time for example).
I was trying to optimize the performance of a multi-threaded code in which multiple threads could execute Jx9 code against the same database. Unqlite is compiled with multithreading support. I noticed that unqlite locks the database's mutex while compiling the Jx9 code, here:
unqlite/src/api.c
Line 922 in f1b7ece
This prevents multiple threads from compiling VMs in parallel. Whether VMs can execute in parallel is another story, but I was at least expecting to be able to compile Jx9 programs concurrently, in particular because timing information shows that this compilation is what takes up most of the time in my scenario. Is there a reason for this part of the code to be serial?
The text was updated successfully, but these errors were encountered: