Links

• Fast Infoset - This article describes a binary representation of XML via ASN.1. This idea has been discussed for a long time, and now some people are working bring it to pass. While I'm not sure I'm in favor of this as an XML purist, as an engineering pragmatist, I can see value of this. In particular, if we're unable to solve our parsing performance issues with DBXML, then an alternative might be to store Fast Infoset data in a Berkeley DB.

Notes

• The trick of using a preloaded repository may not end up speeding up tests as much as we hoped. Andi had already shorted unit test time by using the RAMDB features of Berkeley DB to create the repository files in RAM. The preloaded repository only helps you to load items (such as the core schema). Once those items are loaded, any I/O costs still have to be paid. The problem is that we can't use the preloaded repository trick and create the repository data files in RAM. This means that if you do a lot of I/O after loading pre-loaded items, you get bitten by the fact that RAMDB I/O costs less than real disk I/O's. At a certain point you reach crossover, and then the versions of the tests that use preloading actually get slower than the RAMDB versions.
• Solving design problems by "dimensional analysis". When you have a large design space, one way of narrowing down the possibilities is to take the known possibilities and try to tease out attributes where the possibilities differ. So take stamped items as an example. Some dimensions might be: API (single python object, multiple python objects), storage layout (clustered, not clustered), ACLs (single ACL, multiple ACL). When you've enumerated the dimensions, then you create a space of possible solutions. This helps you to understand the options, and may push you towards a possibility that you hadn't considered but which the dimensional space suggests should exist.

-- TedLeung - 16 Jun 2004