Re: [ANN] faster org-table-to-lisp

[tbanelwebmin]

Nicolas, how did you do that? Your version is 25% faster than mine,
and the code is 33% shorter! Very elegant.

Le 01/05/2020 à 00:35, Nicolas Goaziou a écrit :

> tbanelwebmin <address@hidden> writes:
>
>> I found a way to ensure full backward compatibility. I keep the same
>> signature. When a table is given as a string parameter, it is inserted
>> into a temporary buffer, which is then parsed. Overall, the resulting
>> speed is quite satisfactory.
> Awwww, you didn't like my ELEMENT suggestion.

Sorry, I may not understood what you said:
= Since you're changing the signature, I suggest to provide the table
= element instead of ORG-AT-TABLE-P. AFAICT, `org-babel-read-element',
= through `org-babel-read-table', would greatly benefit from this.

Could you elaborate (if still relevant)?

>
>> I also made the function more tolerant to ill-formed tables: missing
>> "|" or excess of spaces at the end of a row are now gracefully
>> accepted.
> Great!
>
>>             (while (not (re-search-forward "\\=\\s-*\n" end t))
> (re-search-forward "\\=..." ...) -> (looking-at "..." ...)

The side effect of `re-search-forward' was to advance point, while
`looking-at' don't move. This does not matter anymore.

>
> Note that Org does not use \\s- but the simpler [ \t].
>
> Also, the regexp assumes the table end with a newline character, which
> may not be the case.
>
>>               (unless (re-search-forward "\\=\\s-*\\([^|\n]*\\)\\(|?\\)" end 
>> t)
>>                 (user-error "Malformed table at char %s" (point)))
> This cannot happen. The regexp above matches anything, i.e., the empty
> string.

Right! I didn't noticed...

>
>>               (goto-char (match-end 1))
>>               (skip-chars-backward " \t" (match-beginning 1))
>>               (push
>>                (buffer-substring-no-properties (match-beginning 1) (point))
>>                row)
>>               (goto-char (match-end 2)))
>>             (push (nreverse row) table)))
>>         (nreverse table)))))
> I applied your suggestion, with a few simplifications. Hopefully, it
> squeezed a bit more the execution time. Let me know!

Yes! 25%
My two unit tests give correct results.

>
>> The new implementation can be more than 100 times faster. This enhances
>> responsiveness of Babel or Gnuplot blocks handling thousands long
>> tables.
> Looks good. However, we didn't change the signature, so I didn't add
> this to ORG-NEWS. It is in the commit message, tho.
>
> Thank you!
>
Nice team work, thank you too!
Thierry Banel