Hi,
> On 13 Jul 2017, at 09:11, jerome pommier <jerome.pomm...@yahoo.fr.INVALID>
> wrote:
>
> 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 ?
iPOJO instruments all fields to intercept reads / writes. If interception time
is too expensive for you, you have found the solution by copying the value into
a local variable. However, the interception methods have been designed to be
inlined by the JIT meaning that the cost should be meaningless in most of the
cases. When you use a profiler, I’m not sure the JIT can apply all the
optimizations.
Clement
> - am I doing something wrong with OSGI framework ?
>
> Thank you for your answers, sincerely,
>
> JP.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
