Re: speeding up Babel Gnuplot

[Thierry Banel <tbanelwebmin@free.fr>]

Le 04/01/2017 23:36, Nicolas Goaziou a écrit :
>
>> Your proposal provides an additional benefit: caching file generation
>> between several invocations of Babel. (The cache in my patch is intended
>> 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 the
>> table, compute the hash, just to discover that the hash was already
>> known. The purpose of the cache was precisely to avoid going through the
>> 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. Remember the issue in the first place was a slow conversion of this huge structure 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 answer is: we record it in the name of the temporary file. Then, before generating 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 additional memory between two Babel invocations. I'm fine with that. It solves the issue. If we really need the additional feature (memory between two invocations), let's begin working on it.