[
Lists Home |
Date Index |
Thread Index
]
+1
My design does all of the things you mention, and more.
I disagree however about optimizing multiple aspects: You must optimize
on as many axii as are appropriate to you if you want a solution that is
the best combination of tradeoffs. It is more difficult to do this of
course, but anything else doesn't meet the requirements, my requirements
at least.
I do of course have strong ordering of what is important, in this order:
CPU processing overhead, memory processing overhead, new semantics for
libraries (fast pointers to support any logical data structure, deltas),
storage/transmission space efficiency, support for binary payloads. This
has led me to consider solutions that don't seem to have been tried
seriously before such as avoiding parsing and serialization altogether
for my main mode of usage.
sdw
Bob Wyman wrote:
>Michael Champion wrote:
>
>
>>It is common sense that you can't optimize
>>both speed and space simultaneously.
>>
>>
> Common sense is great except for when it is wrong (or
>partially wrong). This particular bit of common sense is *often*
>correct, but not always...
> In communications protocols, reducing the "size" of an object
>will increase the speed with which it is communicated... (Speed of
>light is finite...) The same effect applies to memory and disk
>accesses. Speed in these contexts is at least partially related to
>size.
> Use of binary integers rather than their string
>representations can often reduce the size of objects while also
>increasing processing speed because the need to do conversions may be
>eliminated.
> A process that deletes instances of default values in
>representations of an object defined by a schema will often reduce the
>size of the instance. Depending on processing details, such deletions
>can result in speed improvements in addition to those that are the
>direct result of size reduction. (i.e. If you don't provide the
>default, you don't have to process it when creating or reading the
>object.)
> Replacing "begin" and "end" tags in a data stream with a
>"length" count can result in size reductions (if the begin/end tags
>are larger than the count value) while also improving speed by
>eliminating the need to scan for end tags.
> Replacing "tags" with references to a "dictionary" can
>drastically reduce the size of an object (see Xbis, etc.) while also
>making processing more efficient since you can do integer lookups into
>your symbol table rather than mucking about with strings.
> I could go on...
> Nonetheless, the general drift of the "common sense" is
>correct. It is usually not a good idea to attempt to optimize two
>things at the same time. It is also often impossible to optimize two
>things simultaneously. Further, folk who are trying to optimize more
>than one thing at a time are often simply showing that they haven't
>done enough analysis to understand which of the multiple optimization
>axis is actually most important to them.
>
> bob wyman
>
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
--
swilliams@hpti.com http://www.hpti.com Per: sdw@lig.net http://sdw.st
Stephen D. Williams 703-724-0118W 703-995-0407Fax 20147-4622 AIM: sdw
begin:vcard
fn:Stephen Williams
n:Williams;Stephen
email;internet:sdw@lig.net
tel;work:703-724-0118
tel;fax:703-995-0407
tel;pager:sdwpage@lig.net
tel;home:703-729-5405
tel;cell:703-371-9362
x-mozilla-html:TRUE
version:2.1
end:vcard
|
