felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jerome pommier <jerome.pomm...@yahoo.fr.INVALID>
Subject ipojo performance
Date Thu, 13 Jul 2017 07:11:55 GMT
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.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message