Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #61726
| Path | csiph.com!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder3.xlned.com!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail |
|---|---|
| Return-Path | <python-python-list@m.gmane.org> |
| X-Original-To | python-list@python.org |
| Delivered-To | python-list@mail.python.org |
| X-Spam-Status | OK 0.003 |
| X-Spam-Evidence | '*H*': 0.99; '*S*': 0.00; 'else:': 0.03; 'algorithm': 0.04; 'ideally': 0.04; 'pop': 0.05; 'sized': 0.07; 'received:80.91': 0.09; 'received:80.91.229': 0.09; 'received:gmane.org': 0.09; 'received:list': 0.09; 'run,': 0.09; 'comp': 0.16; 'elsewhere.': 0.16; 'in-place': 0.16; 'iterable': 0.16; 'iterables': 0.16; 'once.': 0.16; 'reasonably': 0.16; 'received:80.91.229.3': 0.16; 'received:dip0.t-ipconnect.de': 0.16; 'received:plane.gmane.org': 0.16; 'received:t-ipconnect.de': 0.16; 'slow,': 0.16; 'wrote:': 0.18; 'version.': 0.19; 'fit': 0.20; 'memory': 0.22; 'example': 0.22; 'coding': 0.22; 'header :User-Agent:1': 0.23; 'looks': 0.24; 'skip:v 30': 0.26; 'this:': 0.26; 'least': 0.26; 'values': 0.27; 'header:X-Complaints-To:1': 0.27; 'needed.': 0.30; 'subject:list': 0.30; 'code': 0.31; 'constant': 0.31; "d'aprano": 0.31; 'fast.': 0.31; 'giant': 0.31; 'keys': 0.31; 'lists?': 0.31; 'produces': 0.31; 'steven': 0.31; 'lists': 0.32; "we're": 0.32; 'table': 0.34; 'skip:d 20': 0.34; "i'd": 0.34; 'problem': 0.35; 'except': 0.35; 'something': 0.35; 'but': 0.35; 'there': 0.35; 'version': 0.36; 'doubt': 0.36; 'should': 0.36; 'seconds': 0.37; 'virtual': 0.37; 'so,': 0.37; 'two': 0.37; 'list': 0.37; 'branch': 0.38; 'saves': 0.38; 'to:addr :python-list': 0.38; 'list,': 0.38; 'to:addr:python.org': 0.39; 'received:org': 0.40; 'how': 0.40; 'trading': 0.61; 'save': 0.62; 'times': 0.62; 'more': 0.64; 'talking': 0.65; 'temporary': 0.65; 'here': 0.66; 'between': 0.67; 'determine': 0.67; '2-3': 0.68; 'apart': 0.72; 'million': 0.74; 'cut-off': 0.84; 'improvement,': 0.84; 'good,': 0.91; 'items,': 0.91; 'ratio': 0.91 |
| X-Injected-Via-Gmane | http://gmane.org/ |
| To | python-list@python.org |
| From | Peter Otten <__peter__@web.de> |
| Subject | Re: Optimizing list processing |
| Date | Thu, 12 Dec 2013 16:08:33 +0100 |
| Organization | None |
| References | <52a8fb2d$0$29992$c3e8da3$5496439d@news.astraweb.com> |
| Mime-Version | 1.0 |
| Content-Type | text/plain; charset="ISO-8859-1" |
| Content-Transfer-Encoding | 7Bit |
| X-Gmane-NNTP-Posting-Host | p50849981.dip0.t-ipconnect.de |
| User-Agent | KNode/4.7.3 |
| X-BeenThere | python-list@python.org |
| X-Mailman-Version | 2.1.15 |
| Precedence | list |
| List-Id | General discussion list for the Python programming language <python-list.python.org> |
| List-Unsubscribe | <https://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe> |
| List-Archive | <http://mail.python.org/pipermail/python-list/> |
| List-Post | <mailto:python-list@python.org> |
| List-Help | <mailto:python-list-request@python.org?subject=help> |
| List-Subscribe | <https://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.3999.1386860910.18130.python-list@python.org> (permalink) |
| Lines | 59 |
| NNTP-Posting-Host | 2001:888:2000:d::a6 |
| X-Trace | 1386860910 news.xs4all.nl 2952 [2001:888:2000:d::a6]:56095 |
| X-Complaints-To | abuse@xs4all.nl |
| Xref | csiph.com comp.lang.python:61726 |
Show key headers only | View raw
Steven D'Aprano wrote: > I have some code which produces a list from an iterable using at least > one temporary list, using a Decorate-Sort-Undecorate idiom. The algorithm > looks something like this (simplified): > > table = sorted([(x, i) for i,x in enumerate(iterable)]) > table = [i for x,i in table] > > The problem here is that for large iterables, say 10 million items or so, > this is *painfully* slow, as my system has to page memory like mad to fit > two large lists into memory at once. So I came up with an in-place > version that saves (approximately) two-thirds of the memory needed. > > table = [(x, i) for i,x in enumerate(iterable)] > table.sort() > for x, i in table: > table[i] = x > > For giant iterables (ten million items), this version is a big > improvement, about three times faster than the list comp version. Since > we're talking about the difference between 4 seconds and 12 seconds (plus > an additional 40-80 seconds of general slow-down as the computer pages > memory into and out of virtual memory), this is a good, solid > optimization. > > Except that for more reasonably sized iterables, it's a pessimization. > With one million items, the ratio is the other way around: the list comp > version is 2-3 times faster than the in-place version. For smaller lists, > the ratio varies, but the list comp version is typically around twice as > fast. A good example of trading memory for time. > > So, ideally I'd like to write my code like this: > > > table = [(x, i) for i,x in enumerate(iterable)] > table.sort() > if len(table) < ?????: > table = [i for x,i in table] > else: > for x, i in table: > table[i] = x > > where ????? no doubt will depend on how much memory is available in one > contiguous chunk. > > Is there any way to determine which branch I should run, apart from hard- > coding some arbitrary and constant cut-off value? How about using two lists? keys = list(iterable) values = range(len(keys)) values.sort(key=keys.__getitem__) del keys The intention is to save memory used for the 2-tuples; I don't know if they pop up elsewhere.
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Optimizing list processing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-11 23:54 +0000
Re: Optimizing list processing MRAB <python@mrabarnett.plus.com> - 2013-12-12 00:59 +0000
Re: Optimizing list processing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-12 01:43 +0000
Re: Optimizing list processing MRAB <python@mrabarnett.plus.com> - 2013-12-12 02:09 +0000
Re: Optimizing list processing duncan smith <buzzard@invalid.invalid> - 2013-12-12 01:02 +0000
Re: Optimizing list processing Ben Finney <ben+python@benfinney.id.au> - 2013-12-12 12:18 +1100
Re: Optimizing list processing Terry Reedy <tjreedy@udel.edu> - 2013-12-11 21:26 -0500
Re: Optimizing list processing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-12 12:08 +0000
Re: Optimizing list processing Chris Angelico <rosuav@gmail.com> - 2013-12-12 23:25 +1100
Re: Optimizing list processing MRAB <python@mrabarnett.plus.com> - 2013-12-12 13:32 +0000
Re: Optimizing list processing Chris Angelico <rosuav@gmail.com> - 2013-12-13 01:06 +1100
Re: Optimizing list processing Terry Reedy <tjreedy@udel.edu> - 2013-12-12 13:40 -0500
Re: Optimizing list processing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-13 00:14 +0000
Re: Optimizing list processing Chris Angelico <rosuav@gmail.com> - 2013-12-13 12:01 +1100
Re: Optimizing list processing Stefan Behnel <stefan_ml@behnel.de> - 2013-12-12 12:09 +0100
Re: Optimizing list processing Peter Otten <__peter__@web.de> - 2013-12-12 16:08 +0100
Re: Optimizing list processing Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-12-13 03:01 +0000
Re: Optimizing list processing rusi <rustompmody@gmail.com> - 2013-12-12 21:35 -0800
Re: Optimizing list processing Terry Reedy <tjreedy@udel.edu> - 2013-12-12 13:07 -0500
csiph-web