Babel Gnuplot is quite slow on large tables.
Example: 45 seconds for a 1500 rows table.
Why? Because orgtbl-to-generic is too slow (or too generic). Its
behavior seems to be quadratic O(size^2). Should we bypass it? Should
we try to optimize it?
Here is a fix to speed up the rendering to a mere f
Hello,
Thierry Banel writes:
> Babel Gnuplot is quite slow on large tables.
> Example: 45 seconds for a 1500 rows table.
>
> Why? Because orgtbl-to-generic is too slow (or too generic). Its
> behavior seems to be quadratic O(size^2). Should we bypass it?
I don't think so.
> Should we try to op
Le 29/12/2016 21:04, Nicolas Goaziou a écrit :
> I did some optimizations in master branch. I go below 1 sec for the 1500
> rows table.
Confirmed! Your latest commit givesa huge boost.
>> Here is a fix to speed up the rendering to a mere fraction of a second.
>>
>> #+BEGIN_SRC elisp
>> (defun org-
Babel Gnuplot can be further accelerated. A table is converted to a
temporary file readable by Gnuplot. I found two issues in this process:
1. the temporary file is generated twice,
2. the generation is quadratic.
I have not provided a committable patch because I am not happy with myfixes.
Of cou
Hello,
Thierry Banel writes:
> Babel Gnuplot can be further accelerated. A table is converted to a
> temporary file readable by Gnuplot. I found two issues in this process:
> 1. the temporary file is generated twice,
> 2. the generation is quadratic.
>
> I have not provided a committable patch b
Le 02/01/2017 00:34, Nicolas Goaziou a écrit :
> Hello,
>
> Thierry Banel writes:
>
>> 1. Temporary generated twice
>> Because org-babel-gnuplot-process-vars is called twice.
>>
>> There is no obvious fix. Here is a dirty patch. It caches the name of
>> the temporary file in the 'param' list.
> Th
Here is a patch to avoid generating temporary files multiple times.
There is no way to ensure a single call to
(org-babel-gnuplot-process-vars) without modifying ob-core.el. I don't
want to do that because I would have to change a lot of babel backends.
Thus, I come back to my first light patch.
Hello,
Thierry Banel writes:
> Here is a patch to avoid generating temporary files multiple times.
>
> There is no way to ensure a single call to
> (org-babel-gnuplot-process-vars) without modifying ob-core.el. I don't
> want to do that because I would have to change a lot of babel backends.
> T
Le 03/01/2017 22:55, Nicolas Goaziou a écrit :
> Hello,
>
> Thierry Banel writes:
>
>> Here is a patch to avoid generating temporary files multiple times.
>>
>> There is no way to ensure a single call to
>> (org-babel-gnuplot-process-vars) without modifying ob-core.el. I don't
>> want to do that b
Thierry Banel writes:
> There is no way to ensure a single call to
> (org-babel-gnuplot-process-vars) without modifying ob-core.el. I don't
> want to do that because I would have to change a lot of babel backends.
But that is the right fix to apply, unless there is a reason for the
input vars to b
Le 04/01/2017 18:32, Achim Gratz a écrit :
> Thierry Banel writes:
>> There is no way to ensure a single call to
>> (org-babel-gnuplot-process-vars) without modifying ob-core.el. I don't
>> want to do that because I would have to change a lot of babel backends.
> But that is the right fix to apply,
Hello,
Thierry Banel writes:
>>> (car pair) ;; variable name
>>> - (let* ((val (cdr pair)) ;; variable value
>>> - (lp (listp val)))
>>> - (if lp
>>> + (let ((val (cdr pair))) ;; variable value
>>> + (if (not (listp val))
>>> + val
>>> + (let ((temp-file (
On Wed, 4 Jan 2017, Achim Gratz wrote:
Thierry Banel writes:
There is no way to ensure a single call to
(org-babel-gnuplot-process-vars) without modifying ob-core.el. I don't
want to do that because I would have to change a lot of babel backends.
But that is the right fix to apply, unless the
Le 05/01/2017 00:15, Charles C. Berry a écrit :
> On Wed, 4 Jan 2017, Achim Gratz wrote:
>
>
> I'm late to this party, but AFAICS input vars are processed just once.
>
> Running this:
>
> #+BEGIN_SRC emacs-lisp :var a=(setq runvar (+ 1 runvar))
> a
> #+END_SRC
>
> increments runvar by one each time
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 t
Hello,
Thierry Banel writes:
> 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 fa
Le 06/01/2017 10:41, Nicolas Goaziou a écrit :
> Hello,
>
> Thierry Banel writes:
>
>> 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
17 matches
Mail list logo
