cson  Artifact Content

Artifact 13dca03411474adfb0f1ec632c7fc68da1fe0699:

Wiki page [News] by stephan 2011-05-09 17:58:46.
D 2011-05-09T17:58:46.296
L News
P 9bedf9fd1f5181a6b95010dbbbd29c1d6d41cd7e
U stephan
W 4415
<strong>ACHTUNG: THIS PAGE IS NOW MAINTAINED IN THE NEW WIKI:</strong> [http://whiki.wanderinghorse.net/wikis/cson/?page=News]

<h1>cson news</h1>

Newest items are at the top...

   *  Started porting wiki pages over to a new platform. Going forward the cson wiki will be maintained at [http://whiki.wanderinghorse.net/wikis/cson/].

   *  Added several convenience routines to [cson_cpdo] for binding <tt>cson_value</tt> (JSON) objects to db columns and parsing JSON from those columns.

   *  Added [cson_sessmgr_whio_epfs] [cson_session] storage back-end.

   *  Added an on-disk-hashtable-based session manager to [cson_session].

   *  Added the [select-to-json] application.
   *  Added initial support for handling form-urlencoded HTTP POST data. Seems to work.

   *  Moved the [cson_cgi] API into the trunk. Created several different [AmalgamationBuild|amalgamation build] variants providing various levels of features.

   *  The new [cson_cgi] API is basically functional.

   *  Added <tt>cson_value_clone()</tt> to deeply copy JSON values.
   *  Pulled the reference-counting code into the trunk. It is now legal for a given <tt>cson_value</tt> instance to be inserted into multiple object/array containers or into the same container multiple times, provided that no cycles are introduced (cycles are still strictly illegal). This feature costs us 4 bytes of memory per value instance (boo!) but gives us a good deal more flexibility in what we can do with <tt>cson_value</tt> instances (yeah!).


   *  Started work on a branch which uses reference counting to allow value instances to be inserted multiple times into the same container or across different containers. The <em>No Cycles</em> rule still applies, however. This feature adds a bit of memory overhead (4 bytes/value) but should enable us to do more interesting things with the object trees. This code is currently in the <tt>with-refcount</tt> branch, and i'm not yet decided as to whether to pull it into the trunk.

   *  Manuel R&uuml;lke kindly pointed out that someone (a bot) had vandalized all the wiki pages and tickets in this site. While no source code appears to have been violated, the repository has been re-built from known-clean sources.

   *  Added [cson_sqlite3].
   *  Some of the routines, like <tt>cson_value_new()</tt> and <tt>cson_value_set_xxx()</tt>, have been removed from the public API because they are easy to mis-use (in terms of memory management) and because they make implementing certain memory allocation optimizations impossible.
   *  Internal allocation optimizations have cut the total number of calls to <tt>malloc()</tt> by 20-30% for "some average test input." Certain internal constant values (e.g. true, false, null, integer 0, double 0.0, and empty strings) now internally use shared value instances. A minor optimization in the parser cuts the total number of allocations somewhat, but does not significantly change the total amount of memory allocated.
   *  We no longer need to dynamically allocate integer values for platforms where <tt>(void *)</tt> is big enough to hold a <tt>cson_int_t</tt> value. This is a compile-time option defaulting to 32-bit behaviour (i.e. dynamically allocate integer values) if it cannot automatically determine (at preprocessor time) that your <tt>(void *)</tt> is big enough to hold a <tt>cson_int_t</tt> value. Interestingly, in my tests this cuts down the number of allocations compared to 32-bit builds, but it does not cut the actual amount of memory used when compared to 32-bit builds because the overhead of the larger pointer size makes such a difference on 64-bit builds.
   *  Yet more optimizations in how object keys are handled saves us one allocation and 1 strcpy op, further reducing total number of allocations made during parsing by about 12-14% in my tests.
  *  In total, and the above optimizations have cut malloc calls (when parsing) by about 30-40% for my tests, and total memory usage by 15-20%, compared to 36 hours ago. These results are for 64-bit builds, which might not have to dynamically allocate integers. On 32-bit platforms, or when cson is built without "large void pointer" support, that particular optimization doesn't apply.

Z a29cd3856afa8744416bbdcf3152550a