tags:

views:

649

answers:

3

Our main program is in java but the code that extracts our data from storage is written in C. I need to build an HDF5 file from extracted data. Would it be better to use JNI to call the C code to get the data and then build the HDF5 file from Java or to build the HDF5 from the C code?

I have little experience with JNI or C.

Also One of our main criteria is performance. How much of a performance hit is there when using JNI?

A: 

Looks to me that since you have little experience with C, your best choice is to do it from withing Java.. JNI is really not that bad.

AlexFerrer
+2  A: 

The function call boundary is "slow", so if you're doing many calls to your native routine, then performance will suffer.

An example of the kind of thing that may benefit from moving to JNI (I emphasize may, because Java is more than fast enough for many purposes) would be a routine to do some sort of image processing on a large bitmap. But to call a JNI routine for each pixel would be much, much slower than doing it within a loop in pure Java.

Extracting data from one format to another is, frankly, the kind of thing best done in a "scripting" language like Python, and will never be bound by CPU. Rather, the disk speed is going to be way, way slower than any language interpreter.

Jonathan Feinberg
A: 

I'm not familiar at all with the HDF interfaces other than the C one, so I cannot really compare for you.

I would point out that this is the API which all other interfaces use, so if you're finding that you need to eek out the maximum performance then the C API is going to be the best.

There is also a question about what parts of the API are available to you. For example I originally started with the C++ interface. Some APIs were still only available in the C API. This is not a problem when you're using C & C++ but it may be a problem if an API you need is not available to you.

Having said that, you do need to have your head screwed on in terms of the object model of C: eg. use of pointers, handles etc.

Richard Corden