Re: [PATCH] Fix massive slowdown in org-id-find

[Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>]

Nicolas Goaziou wrote:
> Florian Beck <fb-ZlLO5Ova5IRn68oJJulU0Q@public.gmane.org> writes:
>
>> the recent changes in org-id (presumably
>> 8cdb2eef0f9f98f9e00a5e689decfe341fe0c6ec) lead to a massive slowdown.
>
> Would you mind elaborating a bit? Slow down doing what? In which cases?
> Could you profile it?
>
>> org-id-find is slow as it is, now I find it almost unusable.
>>
>> Attached patch provides a fix.
>
> Thanks. However, your patch is (partly) wrong.
>
>> -	  (re (org-re-property property nil (not value))))
>> -      (catch 'exit
>> -	(while (re-search-forward re nil t)
>> -	  (when (if value (equal value (org-entry-get (point) property nil t))
>> -		  (org-entry-get (point) property nil t))
>> -	    (throw 'exit (progn (org-back-to-heading t) (point)))))))))
>> +	  (re (org-re-property property nil (not value) value)))
>> +      (when (re-search-forward re nil t)
>> +	(org-back-to-heading t)
>> +	(point)))))
>
> Here, it catches false positives, e.g., lines looking like properties in
> example blocks. It also overlooks accumulated values. It should fail
> with "make test".
>
> However, the optional VALUE argument is nice (I think some profiling
> would still be welcome, tho).

For my own information, does one know if it's possible to integrate
profiling tests in ERT?  So that one could write that if test X takes
more than 2 s (for example), the test would fail?

Best regards,
  Seb

-- 
Sebastien Vauban