On Thu, Jul 19, 2012 at 02:53:35PM +0200, Stephan Bergmann wrote:
> On 07/19/2012 02:38 PM, Lionel Elie Mamane wrote:
>> On Thu, Jul 19, 2012 at 02:12:30PM +0200, Stephan Bergmann wrote:
>>> On 07/18/2012 10:06 AM, Lionel Elie Mamane wrote:
>>> I noticed that there are truckloads of calls to
>>> m_pVm->AttachCurrentThread from
>>> jvmaccess::VirtualMachine::attachThread
>>> (jvmaccess/source/virtualmachine.cxx). Such "outermost" calls into
>>> JNI (i.e., not recursively from a thread that is already in a JNI
>>> call, where jvmaccess::VirtualMachine::attachThread would be cheap)
>>> are always expensive (...). The LO database code is notorious for
>>> making truckloads of such expensive outermost JNI calls, (...)
>> Try to give me an idea what would cause such calls. Is it Java code
>> calling C(++) code (presumably through UNO) or C(++) code calling Java
>> code (again presumably through UNO)?
> Grepping for jvmaccess::VirtualMachine::AttachGuard in connectivity
> and dbaccess should show the places where this is done.
It is wrapped in a SDBThreadAttach class, and this grep yields the
expected places. Good, I see now.
>> For example, to minimise the number of Java calls from C++ , maybe we
>> could, when we retrieve a whole row through JDBC, doing this from Java
>> code instead of from C++ code:
>> for (i=0; i < row->getNumberOfColumns; ++i)
>> cacheEntry[i]=row->getColumnValue(i);
>> This would bring us down from one call per column to one call per row,
>> hopefully without duplicating *too* *much* logic between a C++ version
>> and a Java version.
> Yes, this could be helpful. (When I discussed this with Ocke years
> ago, he always claimed there it was not possible to redesign the
> connectivity/dbaccess code to reduce the number of such "outermost"
> JNI calls, though.)
Well, I haven't thought of a clean way to do it yet; several
approaches exist. I'll have to sleep on it. Listing them here mostly
not to forget them.
One idea is to extend our SDBC API (which is basically a C++ version
of JDBC, which is an extension of ODBC, which is an extension of
X/Open SQL CLI, ...); it currently has only "retrieve one column
value"; we'd add an *optional* "get a whole row". If the optional
extension is not implemented, the code would fallback to a C++
implementation of "get a whole row" that makes multiple calls to
"retrieve one column value".
Replace source/drivers/jdbc/JStatement.cxx (and friends), which *are*
called through UNO, by a full-Java implementation; ah no, that
wouldn't help, since each UNO call would pass the expensive C++/Java
barrier :-|
Change source/drivers/jdbc/JStatement.cxx (and friends) to retrieve
the whole row (through an ad-hoc Java function) and cache it? Which
would make us a *third* level of caching, but well... Maybe it can
cooperate with KeySet so that KeySet does not cache again in this
case. Hmmm... the caching nature of KeySet was introduced because of
ODBC limitations; maybe we could push that to drivers (through a
helper wrapper class they can use to provide this):
- the SDBC-ODBC layer would use the helper class "as is"; since it is
to blame for the limitations that introduce the need for
caching... Only it would suffer from the consequences.
- the SDBC-JDBC layer would have a special implementation that
fetches the whole row in one ad-hoc Java function call.
I'm fond of my trampoline idea, but 't would have to be done in a
clean way; not sure yet how.
--
Lionel
_______________________________________________
LibreOffice mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Locked
