Konrad, Thanks for the guidance, this makes a lot of sense - I was planning to provide a method for printing these objects in the future anyway.
A bit of background: I'm trying to put together a simple framework that uses structures to represent business-domain objects read from a database, similar to the object persistence mechanisms available in JPA, etc. The members of each structure hold the persistent data for the object and I was thinking of using meta data to store ancillary information such as object type, a reference to the context in which the object was loaded and the state of the object (e.g. whether it is consistent with the database or not). A working system would likely have hundreds of thousands of such structures loaded into memory and as such memory usage is a significant concern. By including state data in the meta data, I make it more difficult to share meta data between objects (though maybe interning might be an option?) Alternatively, I could use the meta data for the information that is more or less static (type and context) and make the state part of the main structure data. I'm tending towards the former approach due to the fact that two objects with the same data in different states should still probably be viewed as 'equal' On Apr 27, 9:06 am, Konrad Hinsen <konrad.hin...@laposte.net> wrote: > On 27.04.2009, at 09:42, Meikel Brandmeyer wrote: > > > AFAIU, struct-maps are not an optimisation for efficiency of the > > key lookup, but for the storage space of the keys. So "timings" > > should probably read "memstats". > > If memory is the issue, then creating a single instance of the > metadata map for all values of a type should be sufficient. > > As for timing, key lookup is faster for struct maps than for standard > maps if the number of keys defined in the struct is much smaller than > the total number of keys in the map. This is probably not the case > for most real-life metadata maps. Key lookup can be improved even > more using accessor functions, but that would imply relying on the > metadata being a struct-map for a given struct, which doesn't look > like a great idea. > > Konrad. --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
