Hi, as announced early, here comes a brief overview of the changes I will be committing to SVN soon.
The place where most memory was consumed without need was the prefetching of data from the DB: When the store is accessed, SMW often retrieves more data than required and builds a cache with this. Unfortunately, this prefetching took a lot of effort since many objects were created as containers for the data (which triggers further DB requests since e.g. the datatype of the properties must be determined for making the right containers). I wanted to change this so that only the DB contents is stored, deferring any further requests as long as possible. The problem was that the format used internally to store datavalues is different, depending on the type. Some values only needed a string, some (e.g. SMWWikiPageValue) need multiple data items that are set up with a special method. This prevents a unified storage of prefetched data -- one would still need to know the type of all containers. To solve this, I have change the datavalue API. The methods getXSDValue() and setXSDValue() have been replaced by methods getDBkeys() and setDBkeys(). Instead of a string value, these methods produce and accept arrays of arguments. In this way, all datavalues can be built based on a single array, whatever their type is. Most values use arrays with a single entry only (the former XSDValue) but some have more. Anyone using functions with "XSD" in their name should replace the XSD- functions with the according DBkeys-functions. The old functions will vanish at some point (but not quickly). People who have developed own datatype classes need to do the following: (1) Implement the new interface. This requires a new method parseDBkeys() that is usually a small modification of the old parseXSDValue(). Moreover, a function getDBkeys() must be implements, agein mostly following the old getXSDvalue() but with an array around the result value. (2) The old getXSDValue and parseXSDValue should no longer be implemented. They are provided by the parent class. (3) Every datavalue now has a built-in unstubbing mechanism. Every (public) function that accesses the objects contents should now call $this->unstub() at first. Without this, the object may not be properly initialized. (4) If you had objects with own unstubbing mechanisms (like SMWWikiPageValue had) then you can probably drop those completely. The code from unstub() is likely to be what you need for the new parseDBkeys(). Examples are given by all datavalues in SMW. Besides those major changes, the internal SemData cache size and management was improved to obtain better performance, and queries with ?Category:Something printouts are now much more efficient. Cheers, Markus -- Markus Krötzsch Semantic MediaWiki http://semantic-mediawiki.org http://korrekt.org mar...@semantic-mediawiki.org
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
