Path: csiph.com!usenet.pasdenom.info!dedibox.gegeweb.org!gegeweb.eu!nntpfeed.proxad.net!proxad.net!feeder1-2.proxad.net!news.tele.dk!news.tele.dk!small.news.tele.dk!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.010 X-Spam-Evidence: '*H*': 0.98; '*S*': 0.00; 'plenty': 0.07; 'subject:file': 0.07; 'permissions': 0.09; 'used.': 0.09; 'python': 0.11; 'thread': 0.14; '(low': 0.16; '.txt': 0.16; 'disc': 0.16; 'flush': 0.16; 'from:addr:cs': 0.16; 'from:addr:zip.com.au': 0.16; 'from:name:cameron simpson': 0.16; 'message-id:@cskk.homeip.net': 0.16; 'received:211.29': 0.16; 'received:211.29.132': 0.16; 'received:cskk.homeip.net': 0.16; 'received:homeip.net': 0.16; 'received:optusnet.com.au': 0.16; 'received:syd.optusnet.com.au': 0.16; 'simpson': 0.16; 'sqlite': 0.16; 'subject: \n ': 0.16; 'files.': 0.16; 'wrote:': 0.18; 'commit': 0.19; 'mechanism': 0.19; 'things.': 0.19; 'load': 0.23; 'header:User-Agent:1': 0.23; 'aspect': 0.24; 'config': 0.24; 'lets': 0.24; 'cheers,': 0.24; 'sort': 0.25; "i've": 0.25; 'mention': 0.26; 'switch': 0.26; 'subject:/': 0.26; 'asking': 0.27; 'required.': 0.27; 'gets': 0.27; 'header:In-Reply-To:1': 0.27; 'wondering': 0.29; 'tim': 0.29; "doesn't": 0.30; "i'm": 0.30; 'code': 0.31; 'chase': 0.31; 'forces': 0.31; 'file': 0.32; 'checked': 0.32; 'quite': 0.32; 'text': 0.33; 'open': 0.33; 'except': 0.35; 'really': 0.36; 'accessing': 0.36; 'disk': 0.36; 'received:com.au': 0.36; 'charset:us-ascii': 0.36; 'subject:?': 0.36; 'similar': 0.36; 'level': 0.37; 'received:211': 0.38; 'to:addr:python-list': 0.38; 'files': 0.38; 'issue': 0.38; 'does': 0.39; 'extremely': 0.39; 'sure': 0.39; 'to:addr:python.org': 0.39; 'either': 0.39; 'even': 0.60; 'most': 0.60; 'back': 0.62; 'content-disposition:inline': 0.62; "you'll": 0.62; 'making': 0.63; 'places': 0.64; 'subject:more': 0.64; 'more': 0.64; 'taking': 0.65; 'situation': 0.65; 'benefit': 0.68; 'atomic': 0.84; 'configparser': 0.84; 'drank': 0.84; 'nfs': 0.84; 'safe.': 0.84; 'subject:read': 0.84; 'plain-text': 0.91; 'shares': 0.93 Date: Mon, 16 Dec 2013 10:12:28 +1100 From: Cameron Simpson To: python-list@python.org Subject: Re: Is it more CPU-efficient to read/write config file or read/write sqlite database? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131214101518.69b040dc@bigbox.christie.dr> User-Agent: Mutt/1.5.21 (2010-09-15) References: <20131214101518.69b040dc@bigbox.christie.dr> X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=YYGEuWhf c=1 sm=1 tr=0 a=YuQlxtEQCowy2cfE5kc7TA==:117 a=YuQlxtEQCowy2cfE5kc7TA==:17 a=ZtCCktOnAAAA:8 a=PO7r1zJSAAAA:8 a=LcaDllckn3IA:10 a=AcBfY2YtO3UA:10 a=kj9zAlcOel0A:10 a=vrnE16BAAAAA:8 a=8AHkEIZyAAAA:8 a=pQ66fiTqrssA:10 a=8uR6FKqcAAAA:8 a=MPK07nUipAtBmWzLU_0A:9 a=CjuIK1q_8ugA:10 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 53 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1387150700 news.xs4all.nl 2953 [2001:888:2000:d::a6]:46479 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:61972 On 14Dec2013 10:15, Tim Chase wrote: > On 2013-12-14 07:29, JL wrote: > > I have a number of python processes which communicate with each > > other through writing/reading config text files. The python > > ConfigParser is used. I am wondering if it is more CPU-efficient to > > switch to using sqlite database instead of using configuration > > files. If the software does plenty of reading/writing, is it more > > efficient to use config text files or sqlite database? > > I'm pretty sure that the CPU aspect doesn't really play into things. > A few thoughts: > > + You'll be I/O bound most of the time. Even if you used a ramdisk > to reduce disk access delays, accessing multiple .txt files requires > the OS to do permission-checking each time, while a single sqlite > file gets checked once upon opening the DB initially. > + text-files are fragile unless you take extra pains to keep things > atomic > + sqlite guarantee* atomicity, so you either see all-or-nothing > + sqlite is also very efficient for querying Annoyingly, sqlite: + only lets one process access the db at a time, taking you back to a similar situation as with config files + only lets you access the db from the same thread in which it was opened, outstandingly annoying; I've had to gratuitously refactor code because of this + traditionally, sqlite is extreme fsync() happy; forces a disc level flush on each commit - extremely slow on busy databases, not to mention hard of drives > + sticking with plain-text config files is just asking for some sort > of race-condition or partial-file issue to come up A locking mechanism will be required. Lockfiles work quite well. > + sqlite may give you less CPU load is just an added benefit > > * well, except on NFS shares and other places where file-locking is > unreliable Backing off to config files, making a lock directory is NFS safe. So is opening a lock file for write with zero permissions (low level open with mode=0). Cheers, -- Cameron Simpson I drank what?!? - Socrates