On Tue, Jul 5, 2011 at 9:14 AM, Michael Bedward
<[email protected]>wrote:
> Hi Andrea,
>
> > On the fly compilation of classes will put the results in the permanent
> > generation,
> > depending on the garbage collector chosen it will result in a memory leak
> in
> > the permanent generation (once put there there might be no way to reclaim
> > them).
> > This actually depends on what happens to the classloader that loaded the
> > classes,
> > not sure what the janino one does (like, does every compiled class have
> its
> > own class loader that gets phased out after a while allowing the class
> > bytecode
> > to be garbage collected?), it needs some more investigation.
>
> It provides a per-class classloader by default but you can specify an
> alternative via the SimpleCompiler class (and probably in other ways).
> So far with Jiffle I've just used the default mechanism. If you or
> Simone ever use the Jiffle image operation I imagine this side of
> things will get well tested and tweaked :)
>
Yeah, I have had that in my todo list for a long time, but there is other
stuff that keeps on getting before it...
>
> > The other thing that I'm not sure about is type handling and conversions:
> > much
> > of the slowness in the current system is due to dynamic evaluation and
> > type conversion, however that is also part of the expected behavior, like
> > for
> > example, if one of the data elements had a function that evaluates into a
> > string, but I need a number, the current code would compensate via
> > converters,
> > what would the janino based code do?
> > If it uses converters as well wouldn't we giving up much of the speedup?
>
> I don't think I know enough about GeoTools' innards or the range of
> use cases to provide any useful answer to that but for the restricted
> case of raster rendering the converter issues are minimal or at least
> well defined aren't they ?
>
> Anyway, the IRC chat was nothing more than musing, inspired by the
> dramatic difference that byte-code compilation made to Jiffle runtime
> performance.
>
Indeed I still think it would be very interesting to try out.
I see two use cases here:
- the case were everything in the map is static (which is, afaik, the most
common one):
this can be optimized easily without bytecode engineering, you just
replace with
a implementation that does whatever conversion in the constructor and
applies
some optimized code afterwards
- the case were we have dynamic bits in the map, like function calls.
There we can probably get a speedup by bytecode engineering, but the case
seems
narrow, so a "pay as you go" model sounds better to me, that is, you get
the
speedup if you can setup yourself to have the extra dependency and
deal with the eventual class garbage collection issues. That's why I was
thinking
about a plugin model.
I guess we can get there if someone shows up that really needs ultimate
performance
against the dynamic case? Or are you already the one? :-)
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
