And what is the problem with moving CDataSource to spdb? Alexey Parshin wrote: > The problem is that CQuery is based on CDataSource, so the spdb is > tied to > sptk.. I need to think of something :( > > 2006/7/15, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>: >> >> I started testing it today. I already converted CPPSERV XML config to >> new >> API and that seems to work fine. Saying node.begin() node.end() is bit >> counter-intuitive, but it works just fine. Perhaps these functions >> should have >> been named childrenBegin() childrenEnd()? >> >> Now, real problem is that one is forced to compile in GUI support again. >> libsptk3 is not built in case fltk support is disabled, but libspdb3 >> requires >> CDataSource symbols, which are part of libsptk3. Either the symbols >> should >> be moved, or libsptk3 should be built unconditionally, but with >> different set >> of objects. Seems like CDataSource really does belong to spdb, as well >> as any >> non-SQL data source implementations... >> >> Alexey Parshin wrote: >> > Dear SPTK user, >> > >> > SPTK team proudly presents a new generation of SPTK, built all around >> > XML. >> > You can download version 3.2.2 as *nix tarball >> > <http://sptk.tts-sf.com/sptk-3.2.2.tbz2> and Windows zip >> > <http://sptk.tts-sf.com/sptk-3.2.2.zip>. >> > >> > This version of SPTK introduces a new approach to the data transfer >> > within >> > SPTK and outside, based on XML. Therefore, the XML parser and storage >> > were >> > revoked to work faster and use less memory. >> > >> > Here are the compare results for SPTK versions 3.1 and 3.2. The tests >> > were >> > conducted using examples/xml/xml_test2.cpp. The Windows machine used >> > 2GB of >> > RAM and 3.2GHz Intel processor. The compiler used was VC++ 6. The >> Linux >> > machine used 512MB of RAM and Dual Core 1.83GHz processor. The >> > compiler was >> > gcc 4.1.1. The test creates 500K nodes, writes them to the file, reads >> > them >> > from the file. >> > Operation SPTK 3.1, Windows SPTK 3.2.2, Windows SPTK 3.1, Linux >> SPTK >> > 3.2.2, Linux Create 500K nodes 18.17 sec 2.02 sec 12.08 sec 0.69 >> > sec Save 500K nodes to buffer >> > 19.12 sec 18.81 sec 2.21 sec 2.05 sec Load 500K nodes from buffer >> > 36.08sec >> > 18.45 sec 16.36 sec 5.15 sec sizeof(CXmlNode) 80 20 60 20 >> > Memory >> > allocated for 500K nodes 202.4 Mb 87.7 MB 57 Mb 33 Mb >> > As you can clearly see, the speed up and memory use change are pretty >> > significant. The bad news - the CXmlNode API has changed. The >> access to >> > subnodes and attributes used to be done by using childNodes() and >> > attributes() methodes. Now it is done by using the node itself as a >> > vector >> > of subnodes, and attributes is simply a public variable in CXmlNode >> > class, >> > not a method. >> > >> > The methods used to achieve these performance changes are also >> > interesting. >> > Nodes now are not losing space for the data they can't use. For >> instance, >> > CXmlElement can't have a value, and CXmlText can't have subnodes, >> > attributes, or name. Attributes still use map, but it's only allocated >> if >> > the element has any attributes. >> > >> > The changes in GUI components include the XML connectors save() and >> > load() >> > for the CControl-derived components, CGroup and CScroll. This allows >> > to save >> > and load windows or groups into/from XML files. It's really useful for >> > storing the program state, or the state of settings window, for >> instance. >> > Alexey Parshin, >> > http://www.sptk.net >> > >> >> -- >> Ilya A. Volynets-Evenbakh >> Total Knowledge. CTO >> http://www.total-knowledge.com >> >> > > -- Ilya A. Volynets-Evenbakh Total Knowledge. CTO http://www.total-knowledge.com
List hosted by Total Knowledge