I think Jon Weygandt wrote: > > Any thoughts about a Value factory returning specialized objects > (especially for common Values), by a rough back of the envelope > calculation this could save 50% of the space in the Value object > instance, resulting in an overall savings of 20% application memory > usage.
Yes, I have indeed thought about this -- many times, in fact. Maybe in Jess 8 we'll finally do it. The problem is that it can't be done, unfortunately, without breaking pretty much all existing Java code that uses Jess. "Value" should have been an interface, but because it's a concrete class with public constructors, and so many methods accept Value arguments or return Value results, it can't be changed invisibly. This is a design error from Jess's earliest days that continues to haunt me. One thing that can be done is pooling Value objects. I know of people who have done exactly this, both for values they create themselves and also modifying Jess to do this for internal created Values. One person did it and reported performance improvements, but I couldn't reproduce their results -- in fact I saw performance decreases, which is why such an approach isn't built into Jess. Still, if memory is more important than speed, this could make sense. --------------------------------------------------------- Ernest Friedman-Hill Advanced Software Research Phone: (925) 294-2154 Sandia National Labs FAX: (925) 294-2234 PO Box 969, MS 9012 [EMAIL PROTECTED] Livermore, CA 94550 http://herzberg.ca.sandia.gov -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] --------------------------------------------------------------------
