• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Native XML parser.

 
Ranch Hand
Posts: 2308
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Now as more of more J2EE based application are relying on XML and java based xml parsers are quite slow as compared to the parsers written in native languages like C and C++.Can this be done for improving the speed at which parsing is performed.

Can we not have the core parsing library written in native language and then using native methods from java to access those , so that the parsing becomes fast , real fast.

Though this would make the application dependent of on some OS specific codes.Java will lose the portability but the speed can be must faster that what it is now.

What are the problems that I may enounter if i decide to work on this ?, Is there is already something like this in this space?
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Can we not have the core parsing library written in native language and then using native methods from java to access those , so that the parsing becomes fast , real fast.


So what kind of data structure are you going to build? Java libraries are built around parsers that create Java objects. It is not enough to parse rapidly, you also have to get access to the data you parse.

There are tremendous differences in speed between different techniques within Java - DOM versus SAX, XPath versus more direct methods, etc. etc. - the technique should match the problem and the real problem identified before you go dashing off in all directions.

Is this another "Java is slow" programmer myth or do you have real data.

Bill
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

but the speed can be must faster that what it is now.


Why? The native-to-Java interface simply gets moved to a different layer; it's not clear to me that this would necessarily be faster. Remember that Java is native code - todays JVMs contain quite sophisticated compilers.

As an example where pure Java is faster than using a native library, have a look at the BigDecimal class (and maybe BigInteger as well). It used to be a wrapper around a native library, and got much faster when it was rewritten in pure Java. Of course, there, no native code is running at all, since there's no I/O involved, so the overhead of the native-2-Java interface was in fact removed.
 
Rahul Bhattacharjee
Ranch Hand
Posts: 2308
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I was under the notion that java is slower than other languages.But I did not realize that it might again be much slower if we try to use native libraries using java.If that is the case then can we not make the native method intern() of string class to a pure java method.Can we not maintain the string pool in the heap itself ?
 
William Brogden
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Believe it or not, many many thousands of programmer hours have been expended at Sun, IBM, and other top programming shops in an effort to make Java faster and more efficient over the last 10 or so years. After all, serious money is involved!

I suspect that all the obvious ways to make Java faster have been thoroughly investigated. The present Java is five or six generations from the 1.02 version I worked with over 10 years ago.

There is still plenty of room for improvement in the Java libraries - witness the explosion of open source toolkits at places like sourceforge, so I am not trying to discourage you from seeking improvements, just pointing out that the obvious has already been explored.

Bill
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic