Very Computer

I tried two JDBC drivers for SQL Server 2000: the beta JDBC driver (type 4)
from MS, and JTurbo (type 4?). I always thought these types of drivers would
be faster than JDBC-ODBC drivers. However, I did a test and the results were
just the opposite! The JDBC-ODBC driver (from Sun) is faster! Sometimes
almost twice as fast? I was under the impression that JDBC-ODBC drivers
needed an extra translation when JDBC talked to ODBC, and would be slower.

Here are some figures:

10,000 queries using MS JDBC beta: 68, 65, 66, 65 (all seconds)
10,000 queries using JTurbo: 107, 107 (what the???)
10,000 queries using JDBC-ODBC (Sun): 34, 33, 33

10,000 inserts using MS JDBC beta: 31, 30, 31
10,000 inserts using JTurbo: 25, 24, 24
10,000 inserts using JDBC-ODBC (Sun): 28, 25, 26

JDBC-ODBC connections where done using a system DSN. ***All tests performed
on W2K Server, SQL Server 2000, and using JDK 1.3.1.***

I was pretty amazed that in the query department, JDBC-ODBC really beat the
other two drivers. If the queries are so much faster, why not always use the
JDBC-ODBC driver? Why bother using a JDBC driver at all?

Thanks in advance.

You may well prefer the jdbc-odbc bridge for your application. The reasons I
tell our customers to avoid the jdbc-odbc bridge are that the jdbc-odbc bridge
is buggy, unsupported, and not thread-safe. It also provides the very minimum
jdbc support, such as not being able to re-read column N's data after column
(N+1) has been read, etc. Any bugs in the native component of a type 1 or 2
driver can take down the whole JVM or capture a thread forever. All-Java
drivers are much more reliable, at a minimum because they are Java, they cannot
kill your thread or JVM.

Joe Weinstein at B.E.A.

lets see the code

Quote:> I tried two JDBC drivers for SQL Server 2000: the beta JDBC driver (type
4)
> from MS, and JTurbo (type 4?). I always thought these types of drivers
would
> be faster than JDBC-ODBC drivers. However, I did a test and the results
were
> just the opposite! The JDBC-ODBC driver (from Sun) is faster! Sometimes
> almost twice as fast? I was under the impression that JDBC-ODBC drivers
> needed an extra translation when JDBC talked to ODBC, and would be slower.

> Here are some figures:

> 10,000 queries using MS JDBC beta: 68, 65, 66, 65 (all seconds)
> 10,000 queries using JTurbo: 107, 107 (what the???)
> 10,000 queries using JDBC-ODBC (Sun): 34, 33, 33

> 10,000 inserts using MS JDBC beta: 31, 30, 31
> 10,000 inserts using JTurbo: 25, 24, 24
> 10,000 inserts using JDBC-ODBC (Sun): 28, 25, 26

> JDBC-ODBC connections where done using a system DSN. ***All tests
performed
> on W2K Server, SQL Server 2000, and using JDK 1.3.1.***

> I was pretty amazed that in the query department, JDBC-ODBC really beat
the
> other two drivers. If the queries are so much faster, why not always use
the
> JDBC-ODBC driver? Why bother using a JDBC driver at all?

> Thanks in advance.

I've always thought that ODBC drivers would be faster as they are
implemented in C which
is an order of magnatude faster than Java (Dispite what Sun tries to tell
us).
There are also a few published bench marks by JDBC vendors and these too
show that JDBC-ODBC is faster.
Our experience with JDBC-ODBC does show its short commings. The most
frustating is that you can
have only a single hstatement open on a given connection. This isn't very
practical in real-world applications.
For this reason alone we have move to a pure Java JDBC driver, it certainly
wasn't for the performance.

Regards,
Brett.

Quote:> I tried two JDBC drivers for SQL Server 2000: the beta JDBC driver (type
4)
> from MS, and JTurbo (type 4?). I always thought these types of drivers
would
> be faster than JDBC-ODBC drivers. However, I did a test and the results
were
> just the opposite! The JDBC-ODBC driver (from Sun) is faster! Sometimes
> almost twice as fast? I was under the impression that JDBC-ODBC drivers
> needed an extra translation when JDBC talked to ODBC, and would be slower.

> Here are some figures:

> 10,000 queries using MS JDBC beta: 68, 65, 66, 65 (all seconds)
> 10,000 queries using JTurbo: 107, 107 (what the???)
> 10,000 queries using JDBC-ODBC (Sun): 34, 33, 33

> 10,000 inserts using MS JDBC beta: 31, 30, 31
> 10,000 inserts using JTurbo: 25, 24, 24
> 10,000 inserts using JDBC-ODBC (Sun): 28, 25, 26

> JDBC-ODBC connections where done using a system DSN. ***All tests
performed
> on W2K Server, SQL Server 2000, and using JDK 1.3.1.***

> I was pretty amazed that in the query department, JDBC-ODBC really beat
the
> other two drivers. If the queries are so much faster, why not always use
the
> JDBC-ODBC driver? Why bother using a JDBC driver at all?

> Thanks in advance.

Order of magnitude faster? That hasn't been true for years.

I suspect the real reason is more likely to be in the sheer number of
layers the data has to travel through - I suspect the ODBC driver is
more likely to be able to get directly to the guts of the database, so
there's just the JDBC-ODBC bit to go through. It can all do things
directly in memory, with no networking (which is going to give some
overhead, even for local connections).

I'd be interested to see what performed better against a pure Java
database which provided a native ODBC interface and a *direct* JDBC
layer - ie trying to reverse the number of layers you had to go through.
My guess is that then using a pure Java JDBC driver would get higher
performance than going through ODBC.

This is only a guess, mind you - I really just don't think the speed of
Java (which in most benchmarks I've seen is now between 5 and 20% behind
C for most things, depending on what exactly you're doing) is the issue
here.

--

http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

For any real world applications I would condend to Java is an order of
magnitued slower than C++. Just compare Forte with Visual J++ or any other
C++ IDE.
You also state that

Quote:> I suspect the ODBC driver is
> more likely to be able to get directly to the guts of the database, so
> there's just the JDBC-ODBC bit to go through.

The MS ODBC and JDBC drivers both use TDS which is a communications protocol
for accessing both Sybase and SQL server. TDS operates over some sort of
connection (TCP, Named pipes etc). As such both JDBC-ODBC and the pure JDBC
drivers are esentially accessing the db in the same manner. In fact the
JDBC-ODBC driver must go through more layers than the pure JDBC driver as it
must make a JNI transition. I wouldn't put to much weight behind the cost of
on the JNI translation as that does appear to be fairly quick from my
experience.

Regards,
Brett.

Then compare Eclipse, or CodeGuide, both of which are very nippy and
both written in Java. I've been writing some C++ recently and have found
Visual Studio painfully slow compared with Eclipse.

Can you name many individual tasks in Java which (when written
correctly) *are* an "order of magnitude" slower than C/C++?

Quote:> You also state that
> > I suspect the ODBC driver is
> > more likely to be able to get directly to the guts of the database, so
> > there's just the JDBC-ODBC bit to go through.

> The MS ODBC and JDBC drivers both use TDS which is a communications protocol
> for accessing both Sybase and SQL server. TDS operates over some sort of
> connection (TCP, Named pipes etc). As such both JDBC-ODBC and the pure JDBC
> drivers are esentially accessing the db in the same manner. In fact the
> JDBC-ODBC driver must go through more layers than the pure JDBC driver as it
> must make a JNI transition. I wouldn't put to much weight behind the cost of
> on the JNI translation as that does appear to be fairly quick from my
> experience.

JNI is pretty quick - and I wouldn't be at all surprised if "named
pipes, etc" ended up being *considerably* faster than the external
interface which will has to use TCP.

I'd be interested to see a profile of the pure Java performance,
actually - it should be fairly easy to use the JVM profiling API to find
out how much of the time is actually spent in processing Java. If you're
interested, I'll see what I can do - mind you, the SQL server I'd be
talking to is on a different box; I don't have it installed locally. Let
me know if you want me to try it...

--

http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

I'm afraid your living in a bit of a dreamworld (no offense!) if you think
Java is faster than C++.  Java pays a performance penalty for being platform
independant (unless its running natively) as I am sure you are away it runs
in bytecode rather than machine code  etc etc etc ...... [snip the
explaination that I'm sure everyone knows]

Specific functions in Java that are slower are often related to graphics eg
JFrame but generally java apps are slower (I run Komodo a Java based IDE
that is seriously slow to start up and seriously slow to open files etc -
theres always a long pause before anything happens (not matter the hardware
or Linux / Windows)).

I think you probably found Visual Studio slower as its a very large IDE
compared to a lightweight Java IDE?  I don't know for certain as I haven't
used your Eclipse, CodeGuide but I do know from personal experience that
Forte (a Sun App no less!) is painfully slow.

As for JDBC functions compared with those in other languages - thats another
matter and something I could help to benchmark (I use PHP for web / db stuff
but am considering using JSP as I also know Java).  Something I might take
up when I get a spare moment.

Cheers

Oliver Cronk

Where did I say it was? I said that in one particular set-up, it may be
faster to go to a database with pure Java than with a C app using ODBC.

Quote:> Java pays a performance penalty for being platform
> independant (unless its running natively) as I am sure you are away it runs
> in bytecode rather than machine code  etc etc etc ...... [snip the
> explaination that I'm sure everyone knows]

You seem not to know it, actually. Very little of Java is interpreted on
most machines these days. Almost all of the time it *is* running
natively. It's generally still a *little* slower than normal C/C++, but
not a lot - and certainly not enough to explain these JDBC-ODBC
discrepancies, I suspect.

If you really believe that Java is still run in byte code usually, I
suggest you try the difference between the classic VM shipped with 1.3
(invoke with -classic) and the HotSpot VM which comes by default. If the
difference isn't in JITting (ie running natively, not in bytecode) then
please explain the performance difference - and that generally *is* an
order of magnitude...

Quote:> Specific functions in Java that are slower are often related to graphics

Note the words "order of magnitude" in my previous post. Java GUIs often
*are* a bit slower than native ones, but *not* an order of magnitude
slower - and yes, I'd agree that this *is* one of the areas in which
Java is slowest.

Quote:> eg JFrame but generally java apps are slower (I run Komodo a Java based IDE
> that is seriously slow to start up and seriously slow to open files etc -
> theres always a long pause before anything happens (not matter the hardware
> or Linux / Windows)).

Yawn. Once more: slow examples don't show that a language is slow.

Swing has improved a bit with 1.4, btw - you might want to try that. I
believe it should be much better on Linux than it was, too. There *is* a
big difference between Linux and Windows in terms of Swing speed. If
you've only been trying Swing apps on Linux, I suggest you try on a
Window box. You may be pleasantly surprised. I don't think 1.4 goes all
the way to removing this problem, but it's certainly meant to improve
it.

Swing is likely to always be a bit slower than native GUI components,
certainly - that *is* one performance penalty which is hard to get
around (and that's one reason why Eclipse is faster than Forte, I
suspect), but it's a platform hit rather than a language hit, and
certainly something which should be irrelevant in this discussion which
is (just to remind you) about JDBC, not GUIs.

Quote:> I think you probably found Visual Studio slower as its a very large IDE
> compared to a lightweight Java IDE?  I don't know for certain as I haven't
> used your Eclipse, CodeGuide but I do know from personal experience that
> Forte (a Sun App no less!) is painfully slow.

Forte is pretty large too, isn't it? You seem unwilling to accept that
one large IDE (Visual Studio) being slow makes C/C++ slow, but rather
overly willing to accept that one large IDE (Forte) being slow makes
Java slow. CodeGuide is pretty light-weight, but Eclipse is far from it.

Unless you're willing to try my counter-examples, you don't really have
much of a position to argue from, IMO.

--

http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

There is an article mentioned that SQL JDBC has a memory leak issue and
couldn't handle requests enough to pass their benchmark criteria.

http://www.eweek.com/article/0,3658,s=708&a=23115,00.asp