Re: master 82cc1f4fda1: Revert use of seq-count in shr-count

Re: master 82cc1f4fda1: Revert use of seq-count in shr-count

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> branch: master
> commit 82cc1f4fda19a635cc29577a4da051cf3e062afe
> Author: Stefan Kangas <stefankangas@gmail.com>
> Commit: Stefan Kangas <stefankangas@gmail.com>
>
>     Revert use of seq-count in shr-count
>     
>     * lisp/net/shr.el (shr-count): Prefer handwritten code to using
>     'seq-count', as it's more performant.
>     Problem reported by Mattias Engdegård <mattiase@acm.org>.

With seq becoming more and more popular, is there any conceivable way of
making it faster as well?  The overhead of generic functional-call
dispatching always has me weary of using the library, or at the very
least has me think about it twice as it is convenient.  Is there some
way to use the type inference that native compilation appears to provide
to statically determine what implementation to use?

> ---
>  lisp/net/shr.el | 11 +++++++----
>  1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/lisp/net/shr.el b/lisp/net/shr.el
> index 84033c31ef4..645e1cc51e5 100644
> --- a/lisp/net/shr.el
> +++ b/lisp/net/shr.el
> @@ -2617,10 +2617,13 @@ flags that control whether to collect or render objects."
>      columns))
>  
>  (defun shr-count (dom elem)
> -  (seq-count (lambda (sub)
> -               (and (not (stringp sub))
> -                    (eq (dom-tag sub) elem)))
> -             (dom-children dom)))
> +  ;; This is faster than `seq-count', and shr can use it.
> +  (let ((i 0))
> +    (dolist (sub (dom-children dom))
> +      (when (and (not (stringp sub))
> +                 (eq (dom-tag sub) elem))
> +        (setq i (1+ i))))
> +    i))
>  
>  (defun shr-max-columns (dom)
>    (let ((max 0)

Re: master 82cc1f4fda1: Revert use of seq-count in shr-count

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 04 Sep 2023 20:54:25 +0000
> 
> With seq becoming more and more popular, is there any conceivable way of
> making it faster as well?  The overhead of generic functional-call
> dispatching always has me weary of using the library, or at the very
> least has me think about it twice as it is convenient.  Is there some
> way to use the type inference that native compilation appears to provide
> to statically determine what implementation to use?

I think we should start by measuring its actual performance as
compared to more "traditional" implementations.  Then we will have the
base line and data for making the decisions.

Re: master 82cc1f4fda1: Revert use of seq-count in shr-count

[Karthik Chikmagalur]

> I think we should start by measuring its actual performance as
> compared to more "traditional" implementations.  Then we will have the
> base line and data for making the decisions.

There are some benchmarks by Kisaragi Hiu comparing seq, cl-lib and dash
on Emacs 28.1 here:

https://kisaragi-hiu.com/performance-cl-lib-dash-seq/

seq appears to be much slower than cl-lib.

Karthik

Re: master 82cc1f4fda1: Revert use of seq-count in shr-count

[Eli Zaretskii]

> From: Karthik Chikmagalur <karthikchikmagalur@gmail.com>
> Cc: emacs-devel@gnu.org, stefankangas@gmail.com
> Date: Tue, 05 Sep 2023 17:02:03 -0700
> 
> > I think we should start by measuring its actual performance as
> > compared to more "traditional" implementations.  Then we will have the
> > base line and data for making the decisions.
> 
> There are some benchmarks by Kisaragi Hiu comparing seq, cl-lib and dash
> on Emacs 28.1 here:
> 
> https://kisaragi-hiu.com/performance-cl-lib-dash-seq/
> 
> seq appears to be much slower than cl-lib.

Then I agree that we should convert to seq with caution, only where we
are sure that the slowdown won't matter much, and we should always
time the old vs the new code before making the decision.

Re: master 82cc1f4fda1: Revert use of seq-count in shr-count

[Eli Zaretskii]

> Date: Wed, 06 Sep 2023 14:34:35 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: philipk@posteo.net, emacs-devel@gnu.org, stefankangas@gmail.com
> 
> > From: Karthik Chikmagalur <karthikchikmagalur@gmail.com>
> > Cc: emacs-devel@gnu.org, stefankangas@gmail.com
> > Date: Tue, 05 Sep 2023 17:02:03 -0700
> > 
> > > I think we should start by measuring its actual performance as
> > > compared to more "traditional" implementations.  Then we will have the
> > > base line and data for making the decisions.
> > 
> > There are some benchmarks by Kisaragi Hiu comparing seq, cl-lib and dash
> > on Emacs 28.1 here:
> > 
> > https://kisaragi-hiu.com/performance-cl-lib-dash-seq/
> > 
> > seq appears to be much slower than cl-lib.
> 
> Then I agree that we should convert to seq with caution, only where we
> are sure that the slowdown won't matter much, and we should always
> time the old vs the new code before making the decision.

Of course, speeding up seq would be even better.

Re: master 82cc1f4fda1: Revert use of seq-count in shr-count

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 06 Sep 2023 14:34:35 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: philipk@posteo.net, emacs-devel@gnu.org, stefankangas@gmail.com
>> 
>> > From: Karthik Chikmagalur <karthikchikmagalur@gmail.com>
>> > Cc: emacs-devel@gnu.org, stefankangas@gmail.com
>> > Date: Tue, 05 Sep 2023 17:02:03 -0700
>> > 
>> > > I think we should start by measuring its actual performance as
>> > > compared to more "traditional" implementations.  Then we will have the
>> > > base line and data for making the decisions.
>> > 
>> > There are some benchmarks by Kisaragi Hiu comparing seq, cl-lib and dash
>> > on Emacs 28.1 here:
>> > 
>> > https://kisaragi-hiu.com/performance-cl-lib-dash-seq/
>> > 
>> > seq appears to be much slower than cl-lib.
>> 
>> Then I agree that we should convert to seq with caution, only where we
>> are sure that the slowdown won't matter much, and we should always
>> time the old vs the new code before making the decision.
>
> Of course, speeding up seq would be even better.

There seems to be ways for common lisp to statically dispatch the right
implementations, but I don't understand enough of it to judge if
something like this would be possible for cl-generic:
https://github.com/marcoheisig/fast-generic-functions