From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Banel Subject: Re: speeding up Babel Gnuplot Date: Thu, 05 Jan 2017 21:47:44 +0100 Message-ID: <586EB0F0.7070400@free.fr> References: <5864217C.7060001@free.fr> <586963CB.1000006@free.fr> <87d1g6qrqh.fsf@nicolasgoaziou.fr> <586AB3DB.6070702@free.fr> <586C1A53.90601@free.fr> <87wpebbygr.fsf@nicolasgoaziou.fr> <586C2E80.4050805@free.fr> <87d1g2sba9.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:44151) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cPEwy-0007jf-Ow for emacs-orgmode@gnu.org; Thu, 05 Jan 2017 15:47:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cPEwv-0007Y4-Od for emacs-orgmode@gnu.org; Thu, 05 Jan 2017 15:47:52 -0500 Received: from smtp3-g21.free.fr ([212.27.42.3]:48784) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cPEwv-0007Xs-GO for emacs-orgmode@gnu.org; Thu, 05 Jan 2017 15:47:49 -0500 In-Reply-To: <87d1g2sba9.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Nicolas Goaziou Cc: emacs-orgmode@gnu.org Le 04/01/2017 23:36, Nicolas Goaziou a =E9crit : > >> Your proposal provides an additional benefit: caching file generation >> between several invocations of Babel. (The cache in my patch is intend= ed >> to be used within a single Babel invocation, and is then garbage >> collected.). The drawback is that we need to go through all rows of th= e >> table, compute the hash, just to discover that the hash was already >> known. The purpose of the cache was precisely to avoid going through t= he >> table again. > I'm not sure to understand. > > I suggest to compute the hash of VAL before it is sent through > `org-babel-gnuplot-table-to-data', i.e., before `orgtbl-to-generic' is > called. There's no "going through the table" involved, is it? > > I have the same understanding. The table is recorded in the `params' parameter in a structure similar to= this: (((:var data (row1..) (row2..) (row3..) (row4..) ... By "going through the table" I mean going through this structure. Remembe= r the issue in the first place was a slow conversion of this huge structu= re into a temporary file. Now we need to convert this huge structure into= a hash. Ok, let us assume hashing is faster than writing to disk. Now, what do we do with this hash? Were do we record it? The obvious answ= er is: we record it in the name of the temporary file. Then, before gener= ating a file we compute the hash and see if there is already a temporary = file with this hash in its name. It is heavier than my proposed `param' cache, but it provides an addition= al memory between two Babel invocations. I'm fine with that. It solves th= e issue. If we really need the additional feature (memory between two inv= ocations), let's begin working on it.