Dear all, after having spend a bit of time optimizing the n-body benchmark, I had an idea for another implementation of structures.
- Create a java object Structure, that contains a pointer to a persistent hash map and a private abstract class Field, containing a method set and a method get, both takes a Structure object as well as the usual arguments). - When the user want to define a new structure type foo with fields a b and c, * create an object Foo inheriting Structure with fields a, b and c. * create a static initial persistent hash-map whose entries corresponding to a b and c contain an object of type Field referencing to the field a, b and c. - accessors for this foo structures are generated as a macro: access foo a x -----> (let [#^Foo foo# x] (. x a)) accessor ... = fn [x] (access ... x) - updaters clones and sets the right field of the Foo object. - Fields might have types, primitive or not. You still keep the interface as a persistent hash-map, by using the hash-map inside the structure object. On each get, a get is performed in the table, if it returns: * a Field object, then a get is performed on that object. Returning the content of the field. * else the result is directly forwarded, Setting is similar. - Transient version are made in O(1) by copying the structure and putting the hash map in transient mode. Transient set! is made by direct setting. This implementation presents, I think, the same observational behavior than the current one. It might be slightly slower than the current one for access of non static fields, but is probably very very close from using directly java objects when using with accessors, especially in a transient way. (There is only one field more - the one used to hold the hash-map in the structures - compared to the java encoding, get is the same as the java access to the object and transient set is the same too). Moreover, this implementation makes a nice use of having very fast access to Java objects in Clojure. Does it seems like a good idea? Has it already been thought of and considered as a bad thing to do for a reason I didn't see? I don't think it should replace the current implementation but having another one with different performance characteristics could be a good thing. If it seems helpful I would be happy to help to implement it, as it may be very useful to the kind of programs I am writing, as well as allowing Clojure to shine in micro-benchmarks. Best regards, Nicolas. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
