Differences between revisions 3 and 4
Revision 3 as of 2006-05-28 22:39:28
Size: 1530
Editor: 213-176-147-230
Revision 4 as of 2008-11-15 14:01:07
Size: 1536
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
   [http://www.python.org/dev/peps/pep-0266/ PEP 266],
   [http://www.python.org/dev/peps/pep-0267/ PEP 267],
   and [http://www.python.org/dev/peps/pep-0280/ PEP 280]
   [[http://www.python.org/dev/peps/pep-0266/|PEP 266]],
   [[http://www.python.org/dev/peps/pep-0267/|PEP 267]],
   and [[http://www.python.org/dev/peps/pep-0280/|PEP 280]]
  • Expose/develop pre-allocation arguments/methods for dict/list? API? RichardJones evaluated changes, but disapoointingly found that little or no speed advantage could be gained by preallocation of large structures!

  • Evaluate the PEPs for optimizing global and attribute lookups

Copyless network I/O

A "hot buffer" class was implemented in order to perform I/O and parsing (using struct) without creating or copying strings around. This is compared for performance with a loop that creates strings via slices and concatenates strings. It turns out that the hot buffer version is not much faster (about the same speed) because it replaces string allocations and concatenations with dict lookup in order to access its attributes (position and limit). The version that uses strings is pretty fast since we write it using the string protocol, i.e. no dict lookup is performed. However, by implementing the common use patterns in C we should be able to make parsing of common input (e.g. netstrings) much faster. The hot buffer provides a more intuitive interface to parsing. The fact is that currently the performance gains with the initial version are not significant. (We need to complete some features to measure its impact.)

NeedForSpeed/Deferred (last edited 2008-11-15 14:01:07 by localhost)

Unable to edit the page? See the FrontPage for instructions.