Hello,
As a scientist, I used to program my calculations in JAVA, and since almost one
year I'm doing these using OSGI paradigm, more precisely IPOJO framework. The
programs are much more powerful, and I find huge advantages, of course. Anyhow
I have questions regarding IPOJO performance. Let me give you an example.
I) STARTING PROBLEM
I have a collection of geometric objects (say Triangle and Square), on which I
must do some computations by pairs. Technically I may write something like :
for (Geom g1 : geometricList){
for (Geom g2 : geometricList){
compute(g1,g2) ;
}
}
II) CLARITY
But because the method « compute » should clearly distinct operations when
objects are of types Triangle or Square, the code for « compute » method become
quickly huge and unreadable (furthermore you can imagine that there is other
kinds of geometric objects).
Leading to a much more readable “compute” code, I can partition my objects into
geometric categories with the following code :
for (Geom g1 : geometricList){
for (Geom g2 : TrianglesList){
computeTriangles(g1,g2) ;
}
for (Geom g2 : SquaresList){
computeSquares(g1,g2) ;
}
}
III) OSGI SOLUTION
I find that OSGI allows very simple extensions and management of this coding
structure when computeTriangles, and computeSquares are designed as OSGI
«PairGeometricServices»
for (Geom g1 : geometricList){
for (Geom g2 : TrianglesList){
pairGeometricServiceTriangles.compute (g1,g2) ;
}
for (Geom g2 : SquaresList){
pairGeometricServiceSquares.compute(g1,g2) ;
}
}
« compute » extracts some complicated geometries information on its parameters
« g1 », and « g2 », and because within the « g1 » loop, the object g1 stays the
same it seems better to write something like :
for (Geom g1 : geometricList){
pairGeometricServiceTriangles.setFirst(g1) ;
for (Geom g2 : TrianglesList){
pairGeometricServiceTriangles.compute (g2) ;
}
pairGeometricServiceSquaresInstance.
reconfigure(pairGeometricServiceTriangles.getDict()) ;
for (Geom g2 : SquaresList){
pairGeometricServiceSquares.compute(g2) ;
}
}
Now « setFirst » computes the geometries information for « g1 » and stores them
in some « ServiceProperty » of the associated « PairGeometricService ». The
line «reconfigure(...)» allows « pairGeometricSquares » to be updated with
these «ServiceProperty» values.
IV) BENCHMARKING
As I said in the beginning, I'm very happy with such OSGI's programming
structures which is easily extended and updated. Now, if we look inside the
“compute” implementation of the “PairGeometricServiceSquare” we find something
like:
…..
@ServiceProperty(name=FIRST_LENGTHS)
double[] first_lengths;
….
public void compute(Geom g2){
...
q=xx*yy*first_lentghs[i]+…;
…
}
….
That is the “ServiceProperty” values are heavily accessed within some loops.
Everything is working as expected, but profiling the (very slow) code I found
that more than 80% of the total time for the method “compute” comes from
reading the “ServiceProperty”, appearing as:
fqdnClassName._getfirst_lengths
in the profiler.
The trick is to write a line of code at the beginning of “compute”
double fl[]= first_lengths;
and then to replace “first_length” by “fl” in the code. The extra time has now
disappeared.
V) QUESTIONS
Could you let me know:
- Is there any advice about not using “ServiceProperty” fields as any other
fields, or is it a implementation artifact ?
- am I doing something wrong with OSGI framework ?
Thank you for your answers, sincerely,
JP.
