Poor performance

[walter-weinmann]

OraBench compares the performance of various Oracle database drivers and includes both JDBC.jl and Oracle.jl. There are 10 trials in each benchmark run. In each trial, 100000 rows are inserted into a simple database table and read again. Here is a comparison between JDBC.jl and Oracle.jl:

trial	JDBC.jl	Oracle.jl
best	140592 ms	5410 ms
worst	142797 ms	7076 ms
average	141214 ms	6098 ms

Based on the average value, JDBC.jl is 23 times slower than Oracle.jl!

[ExpandingMan]

I haven't contributed to this package in a while, so what I'm about to say might not reflect recent work, but I recommend thinking of JDBC.jl as a "last ditch solution when all else fails". Indeed, its domain of usefulness has (fortunately) shrunk drastically since both Julia database support has gotten better and more databases move to more easily interoperable solutions such as HTTP. I used to keep an eye on the maintenance of this package to make sure it was working, but I haven't had to look at it at all in quite a long time, and I suspect there are others for who that is true. This package depends strongly on JVM interop and, quite understandably, I don't think there's a ton of people excited to work on that in the Julia community.

TL;DR: If Oracle.jl is faster, I strongly suggest you use it.

Furthermore, unless there are others around who are thinking of putting substantial work into JDBC.jl to address things such as poor performance, I suggest we put some kind of explanation in the README that says something along the lines of "maintained, but should be your last option".

[walter-weinmann]

The picture above shows what the OraBench project is about, namely comparing the performance of different Oracle database drivers. JDBC.jl stands out with extremely poor performance - here the processing of a row takes almost 1 ms. My assumption was that there might be an implementation error in JDBC.jl that causes this huge time delay.

[ExpandingMan]

It's possible, but it's likely that it has something to do with deserialization from Java, which is not an easy thing to fix.

[aviks]

It's my guess that the slowdown is mainly due to the number of copies we make when converting from Java to Julia, but that's only a gut feel, I haven't profiled this formally. I always knew this was slow, the benchmarking does show that the slowdown is pretty egregious.

[ExpandingMan]

@aviks do you think a warning about the current status on the README would be helpful? Are you actively using this package? I would not want to call it "unmaintained" but, again, I don't think there's much incentive to improve this package beyond the bare minimum functionality.

[aviks]

Hi @walter-weinmann

Thanks for reporting these issues. Can I ask, is the read time being measured by running executeQuery and then iterating on the returned resultset. From the code here, that's what I guessed. Can you confirm, if I am looking at the right place?

If that is indeed the case, all the time is being spent in Java and in the communication layer, so I'm not certain we can improve that by much, unfortunately.

[walter-weinmann]

Hi, @aviks that's right.

I doubt that the problem is with the JDBC driver. I have also solved the same problem with Java and Kotlin in connection with the Oracle JDBC driver. But with these two programming languages, there is absolutely no problem with the performance.

[aviks]

Yeah, I'm sure the oracle driver does not have any issues. I meant that the time is spent in the JNI communication layer. In the code you are running, there is not much time spent on the Julia side.

[walter-weinmann]

@aviks i.e. the performance problem is system-dependent - see Baeldung! I will remove JDBC.jl from my project and replace it with an appropriate note.