This is Java
-
<?xml version="1.0" encoding="UTF-8"?>
<Warning against="Java" level="might be high">
<TakeSerious>
If you like to!!! but dont flame me, OK???
</TakeSerious>
<WarningMsg>
Following presentation is not suitable for those whole who cannot see any thing but Java. Readers discretion in highly advised.
<WarningMsg>
</Warning>Recently I had to change some code in Java and found some *major* issues in the code. Some of them were, 1. It used a lot of unnecessary Hashtable (like CMap in MFC and map in STL) 2. Extensive use of _String_s X| 3. lake of calls to cleanup functions like ResultSet.close(), Statement.close() and so on 4. No result caching (performing same operation on same data, so always getting the same result) X| 5. Unnecessary type casting X| and stuff like that. So, I made changes like, 1. Replaced majority of Hashtables with ArrayList (I use ArrayList a lot :-O) and simple C-style Object arrays 2. Removed many _String_s and used _int_s and _long_s 3. Added clean up function calls 4. Improved the algorithm, added result caching, variable re-use (to avoid constructors) and reduced the total number of lines significantly Now, at the end I hardly get a 7% improvement in speed. X| You would say it is Java, it is interpreted and blah blah blah but I think that if I had made such changes in a C++ app it'd give me a huge speed advantage. So at the end I can safely assume that Java treats good code as lousy code. lol :-D One can argue that reducing "Total Number of lines" does not necessarily mean faster code but in this case it DOES mean faster code b/c its a long computation involving _int_s, _long_s, _String_s and such. Also it does have database interaction but thats only 20% of the total algorithm. After digging for possible culprits I have found these, 1. Calls to EJBs (every body knows how slow is RMI-IIOP) 2. Container itself (iPlanet in this case) 3. Last but not least, the one and only, JavaTM X| :) ;) ;P :-D :cool: Farhan Noor Qureshi
-
<?xml version="1.0" encoding="UTF-8"?>
<Warning against="Java" level="might be high">
<TakeSerious>
If you like to!!! but dont flame me, OK???
</TakeSerious>
<WarningMsg>
Following presentation is not suitable for those whole who cannot see any thing but Java. Readers discretion in highly advised.
<WarningMsg>
</Warning>Recently I had to change some code in Java and found some *major* issues in the code. Some of them were, 1. It used a lot of unnecessary Hashtable (like CMap in MFC and map in STL) 2. Extensive use of _String_s X| 3. lake of calls to cleanup functions like ResultSet.close(), Statement.close() and so on 4. No result caching (performing same operation on same data, so always getting the same result) X| 5. Unnecessary type casting X| and stuff like that. So, I made changes like, 1. Replaced majority of Hashtables with ArrayList (I use ArrayList a lot :-O) and simple C-style Object arrays 2. Removed many _String_s and used _int_s and _long_s 3. Added clean up function calls 4. Improved the algorithm, added result caching, variable re-use (to avoid constructors) and reduced the total number of lines significantly Now, at the end I hardly get a 7% improvement in speed. X| You would say it is Java, it is interpreted and blah blah blah but I think that if I had made such changes in a C++ app it'd give me a huge speed advantage. So at the end I can safely assume that Java treats good code as lousy code. lol :-D One can argue that reducing "Total Number of lines" does not necessarily mean faster code but in this case it DOES mean faster code b/c its a long computation involving _int_s, _long_s, _String_s and such. Also it does have database interaction but thats only 20% of the total algorithm. After digging for possible culprits I have found these, 1. Calls to EJBs (every body knows how slow is RMI-IIOP) 2. Container itself (iPlanet in this case) 3. Last but not least, the one and only, JavaTM X| :) ;) ;P :-D :cool: Farhan Noor Qureshi
-
<?xml version="1.0" encoding="UTF-8"?>
<Warning against="Java" level="might be high">
<TakeSerious>
If you like to!!! but dont flame me, OK???
</TakeSerious>
<WarningMsg>
Following presentation is not suitable for those whole who cannot see any thing but Java. Readers discretion in highly advised.
<WarningMsg>
</Warning>Recently I had to change some code in Java and found some *major* issues in the code. Some of them were, 1. It used a lot of unnecessary Hashtable (like CMap in MFC and map in STL) 2. Extensive use of _String_s X| 3. lake of calls to cleanup functions like ResultSet.close(), Statement.close() and so on 4. No result caching (performing same operation on same data, so always getting the same result) X| 5. Unnecessary type casting X| and stuff like that. So, I made changes like, 1. Replaced majority of Hashtables with ArrayList (I use ArrayList a lot :-O) and simple C-style Object arrays 2. Removed many _String_s and used _int_s and _long_s 3. Added clean up function calls 4. Improved the algorithm, added result caching, variable re-use (to avoid constructors) and reduced the total number of lines significantly Now, at the end I hardly get a 7% improvement in speed. X| You would say it is Java, it is interpreted and blah blah blah but I think that if I had made such changes in a C++ app it'd give me a huge speed advantage. So at the end I can safely assume that Java treats good code as lousy code. lol :-D One can argue that reducing "Total Number of lines" does not necessarily mean faster code but in this case it DOES mean faster code b/c its a long computation involving _int_s, _long_s, _String_s and such. Also it does have database interaction but thats only 20% of the total algorithm. After digging for possible culprits I have found these, 1. Calls to EJBs (every body knows how slow is RMI-IIOP) 2. Container itself (iPlanet in this case) 3. Last but not least, the one and only, JavaTM X| :) ;) ;P :-D :cool: Farhan Noor Qureshi
I don't get it, what is the purpose of this post? To say that Java is slow? To say that C++ can be optimized more than Java? OK, so run on a faster computer. OK, so you didn't spend your time chasing memory-related bugs around. OK, so your program runs on Windows and UNIX without recompilation. I guess my point is, everything has a positive and a negative side to it. I personally like C++ better than Java, but Java has some nice benefits, which explains why so many people have embraced it. Regards, Alvaro
-
I don't get it, what is the purpose of this post? To say that Java is slow? To say that C++ can be optimized more than Java? OK, so run on a faster computer. OK, so you didn't spend your time chasing memory-related bugs around. OK, so your program runs on Windows and UNIX without recompilation. I guess my point is, everything has a positive and a negative side to it. I personally like C++ better than Java, but Java has some nice benefits, which explains why so many people have embraced it. Regards, Alvaro
Java has some nice benefits, which explains why so many people have embraced it. And some even tried to embrace and extend ;P Tomasz Sowinski -- http://www.shooltz.com
-
Java has some nice benefits, which explains why so many people have embraced it. And some even tried to embrace and extend ;P Tomasz Sowinski -- http://www.shooltz.com
:D Yes! I don't think anyone can deny Java's influence on [.NET](javascript:alert('.NOT!')). Regards, Alvaro
-
:D Yes! I don't think anyone can deny Java's influence on [.NET](javascript:alert('.NOT!')). Regards, Alvaro
Nothing new in Java that didn't already exist in other forms. Of course, unfortunately, that can be said about most software development these days. :(( When I looked at CLR (which is based a lot of the JM), I nearly fell out of my chair when I noticed very common Forth operations. Maybe one day we will see some REAL advancements in software instead of rehashing the old. Tim Smith Descartes Systems Sciences, Inc.
-
Is there a point to your post, or was this just some sort of "wow, look at me!" self-pleasuring topic?
Ok let me elaborate. My point was “Java is so !@#$%^&*” that even after such hard effort in making the code to run better it does not pay back. :) ;) ;P :-D :cool: Farhan Noor Qureshi
-
I don't get it, what is the purpose of this post? To say that Java is slow? To say that C++ can be optimized more than Java? OK, so run on a faster computer. OK, so you didn't spend your time chasing memory-related bugs around. OK, so your program runs on Windows and UNIX without recompilation. I guess my point is, everything has a positive and a negative side to it. I personally like C++ better than Java, but Java has some nice benefits, which explains why so many people have embraced it. Regards, Alvaro
I don't get it, what is the purpose of this post? :( To say that Java is slow? Yes!!! To say that C++ can be optimized more than Java? Yes :-D OK, so run on a faster computer. OK, so you didn't spend your time chasing memory-related bugs around. OK, so your program runs on Windows and UNIX without recompilation. You have rendered me speechless. :-O I guess my point is, everything has a positive and a negative side to it. :) I personally like C++ better than Java, but Java has some nice benefits, which explains why so many people have embraced it. Yes, I know the "benefits"!!!! Some of those benefits are visible in my original post ;) ;) ;) Regards, Farhan Noor Qureshi
-
<?xml version="1.0" encoding="UTF-8"?>
<Warning against="Java" level="might be high">
<TakeSerious>
If you like to!!! but dont flame me, OK???
</TakeSerious>
<WarningMsg>
Following presentation is not suitable for those whole who cannot see any thing but Java. Readers discretion in highly advised.
<WarningMsg>
</Warning>Recently I had to change some code in Java and found some *major* issues in the code. Some of them were, 1. It used a lot of unnecessary Hashtable (like CMap in MFC and map in STL) 2. Extensive use of _String_s X| 3. lake of calls to cleanup functions like ResultSet.close(), Statement.close() and so on 4. No result caching (performing same operation on same data, so always getting the same result) X| 5. Unnecessary type casting X| and stuff like that. So, I made changes like, 1. Replaced majority of Hashtables with ArrayList (I use ArrayList a lot :-O) and simple C-style Object arrays 2. Removed many _String_s and used _int_s and _long_s 3. Added clean up function calls 4. Improved the algorithm, added result caching, variable re-use (to avoid constructors) and reduced the total number of lines significantly Now, at the end I hardly get a 7% improvement in speed. X| You would say it is Java, it is interpreted and blah blah blah but I think that if I had made such changes in a C++ app it'd give me a huge speed advantage. So at the end I can safely assume that Java treats good code as lousy code. lol :-D One can argue that reducing "Total Number of lines" does not necessarily mean faster code but in this case it DOES mean faster code b/c its a long computation involving _int_s, _long_s, _String_s and such. Also it does have database interaction but thats only 20% of the total algorithm. After digging for possible culprits I have found these, 1. Calls to EJBs (every body knows how slow is RMI-IIOP) 2. Container itself (iPlanet in this case) 3. Last but not least, the one and only, JavaTM X| :) ;) ;P :-D :cool: Farhan Noor Qureshi
Just one little observation. Hashtable is not "something like map in STL" (I'm not sure about MFC CMap). STL map is a balanced binary tree, and searching is slower than with hashtables. Hashtables are almost as fast as arrays (I'm talking about searching only... inserting is another issue). Anyway, I agree that Java is slow. I vote pro drink :beer: