Thanks for all your replies, let see if I can clarify myself; I hope I will not bore you with my long prose
compiling to native code won't make bad algorithms fast.
I guess I should describe a bit what my application is doing, since you mentioned
bad algorithms. Anyway, I think it was/is a very exciting application for me to develop, especially as this was my first real Java program. I learned a lot of things one the way, thanks to books and of course this site. I guess I might as well share it with everyone. Perhaps, there will be someone who will find
fun to illustrate this in RMI.
To start, let me just say my app. includes the following:
File I/O reading Text parsing Sockets and Streams Client/Server Database and SQL This list is logically ordered as they execute within the app.
Let me first begin with a brief description:
This Java application reads/loads data from one text file to one or more relational (Oracle) databases and does transaction processing and maintains synchronization across all data replicas.
The file is structured and has a SQL section in the first half, followed by the data section, which is in logical blocks that represent transactions to be loaded in the database.
I give more detail in each link that I provide. I posted many queries here, and did lots of searching here in the ranch as I was going through my journey. I am mostly satisfied with the speed, but we all like to practice
Moore's Law and I think there is room for performance in my app. Actually, my
very first post was when it all started! I then completed my work as I outlined in my first post, but then I ran into problems and I came back with my
Second post on this issue. I then took
Michael Ernest's advice and re-wrote my application with the client/server model. I had a couple of issues I will not list them all, the biggest of which was related to
Streams.
My thing works and the speed is
acceptable considering the massive updates that it needs to do. Here is a quick outline of how the design.
The server:
The multi-threaded server is located on each box as new Clients connects a new Request object is created which is
running in its own thread.
The Request then sets up the input/output streams with the client socket. Then, using Object Serialization, reads a Command object from the client and does its thing according to the (hmm) "protocol". Upon completion of the Command, a Result Object is sent back to the client containing status conditions and/or any Exceptions.
The Request object creates a local (to the server) Exec object that connects to the local database. The Exec does the SQL operations and commit/rollback as invoked by the Request, which in turn gets the command from the client.
The Client:
A DataReader object is created that reads from the file, the two most important methods are getSQLInsrtunctions() and getData(), all the parsing is done in the DataReader.
The DataReader creates an array of StatementUnit objects, where a StatementUnit represents a single table, num_rows, num_cols, etc.
A Manager Object (or Boss) is created to handle the synchronization of the remote databases. The Manager creates 'n' Client Objects based on the number of
JDBC URLs given on the command line. (Which is sent over and used by the Request and Exec Classes) The Manager gets the info from the DataReader passing it to the Client instances, then waits... using the mutex of the StatementUnit array (object).
Each Client runs in its own thread, and connects via a Socket to the aforementioned Server. The Client follows the (hmm) "protocol" and sends a Command Object over the wire getting back a Result object. Then the client hits a Barrier and waits using the mutex of 'this'. The Barrier 'knows' how many client there are and when the last Client hits the Barrier it notify()s the Manager. And� the cycle begins again until all data from the file has been read.
There is no doubt that the Java app. is more complex then the C program. Nevertheless, the brief description should tell you that the end result of both apps should be the same.
To finish my story and some comparison, the C program is not multi-thread and no client/server thing is involved. I tested 600 transactions executing to 4 database schemas, and it takes about 17 minutes with the C program, and about 4 Minutes with the Java program. However, if I run the same 600 transactions for ONE database the C program runs about 1.5 minutes while the Java thing runs in about the very same 4 minutes.
but the place to start would be a profiler.
And where do I get a profiler and how do I start? I would be interested in at least running it. Thanks,
Also, JIT compilers already compile to Native Code. You just don't see it happen and you still have your bytecode.
�
JIT - A bit of information.
..
Thanks for the link Gregg, now some where in that article it says: "When a JIT is present � The JIT will take the bytecodes and compile them into native code �"
My question to you how do I know if a "JIT is present"?
Here is all that I can give you:
How do I get/install setup the JIT. I remember reading 'somewhere' that the JIT is 'somehow' built-in
Any input is greatly appreciated. BTW, I am thinking of taking the
SCJD exam and I would appreciated your thoughts on that as well.
[ December 11, 2002: Message edited by: Leslie Chaim ]