Re: [RFC] Some new vector procedures (vector-{memq, apply, to-string, ...})

[Eli Zaretskii <eliz@gnu.org>]

> From: Alex Gramiak <agrambot@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Sat, 20 Apr 2019 10:50:28 -0600
> 
> > Doesn't seq.el already provide this functionality?
> 
> Some, but not all. I don't see a vector-partition equivalent
> (seq-partition is different), or a vector-index equivalent
> (seq-find/cl-find return the element instead of the index, and is ~10x
> slower).

Isn't seq-position the equivalent of vector-index?

Anyway, if some algorithms are missing from seq.el, maybe we should
just add them there instead of starting an entirely new family of
primitives?

> > As for speed, did you have any application where the speed of the Lisp
> > implementation was inadequate?
> 
> For vector-memq, the Lisp implementations almost disallow it from being
> used over memq/lists. The equivalent in seq.el, seq-position, is ~100x
> slower for smaller vectors and ~200x for larger (500 elements) vectors.

The factors don't really answer my question.  The question was whether
some real-life application that uses seq.el is so slow that moving
them to C is necessary.  IOW, the question was about absolute times,
not relative times.  If you can describe such use cases, I'd like to
discuss them with the participation of seq.el's maintainer first.

And if we eventually decide that some special cases do require to be
coded in C, I think we'd prefer calling them from seq.el, not
directly.  Otherwise, why have seq.el at all?

> The main two I care about here are vector-memq/vector-member.

Please tell why in more detail.

Thanks.