On 8/25/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > >For the record, I think this is a major case of YAGNI. You appear way > >to obsessed with performance of some microscopic aspect of the > >language. Please stop firing random proposals until you actually have > >working code and proof that it matters. Speeding up microbenchmarks is > >irrelevant. > > Twisted's core loop uses string views to avoid unnecessary copying. This > has proven to be a real-world speedup. This isn't a synthetic benchmark > or a micro-optimization.
OK, that's the kind of data I was hoping for; if this was mentioned before I apologize. Did they implement this in C or in Python? Can you point us to the docs for their API? > I don't understand the resistance. Is it really so earth-shatteringly > surprising that not copying memory unnecessarily is faster than copying > memory unnecessarily? It depends on how much bookkeeping is needed to properly free the underlying buffer when it is no longer referenced, and whether the application repeatedly takes short long-lived slices of long otherwise short-lived buffers. Unless you have a heuristic for deciding to copy at some point, you may waste a lot of space. > If the goal is to avoid speeding up Python programs because views are too > complex or unpythonic or whatever, fine. But there isn't really any > question as to whether or not this is a real optimization. There are many ways to implement views. It has often been proposed to make views an automatic feature of the basic string object. There the optimization in one case has to be weighed against the pessimization in another case (like the bookkeeping overhead everywhere and the worst-case scenario I mentioned above). If views have to be explicitly requested that may not be a problem because the app author will (hopefully) understand the issues. But even if it was just a standard library module, I would worry that many inexperienced programmers would complicate their code by using the string views module without real benefits. Sort of the way some folks have knee-jerk habits to write def foo(x, None=None): if they use None anywhere in the body of the function. This should be done only as a last resort when real-life measurements have shown that foo() is a performance show-stopper. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
