From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: zsh-workers@zsh.org
Subject: Re: Array appends are quadratic
Date: Thu, 3 Dec 2015 23:36:04 +0000 [thread overview]
Message-ID: <20151203233604.GD1955@tarsus.local2> (raw)
In-Reply-To: <20151128193652.777742be@ntlworld.com>
Peter Stephenson wrote on Sat, Nov 28, 2015 at 19:36:52 +0000:
> On Sat, 28 Nov 2015 18:05:17 +0000
> Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > The effort involved in implementing the redoubling allocation (for the
> > other problem indicated in 37236) would be similar: mainly having the
> > array remember the number of allocated slots. I'll have to track done
> > all places in the code that allocate/reallocate arrays, hopefully there
> > aren't too many.
>
> I suspect (though I haven't actually done a search) you're out of luck
> here, as there's a wide assumption that null-terminated char **'s are
> the the way to carray a fixed number of elements with generic contents
> that might get presented to the user. See for example the number of
> uses of mkarry().
I'm not sure I see the problem. Doubling reallocations would require
the array to track its allocated size (the N in «pm->u.arr = alloc(N
* sizeof(void*))», which is strictly greater than its arrlen). I assume
only affect places that modify the array would be affected: that is,
places that modify pm->u.arr directly (list below) and places that call
setfn. So, I think doubling allocations can be made to work, if each
place that modifies the array knows what arrlen() would be after the
modification, in order to be able to cheaply determine whether its
smaller than the allocated length.
So maybe it's better to first teach arrays to know their arrlen in O(1),
before investigating doubling allocations. (Mikael had investigated
this direction.)
Daniel
typeset_single:Src/builtin.c:2428: tdp->arrptr = &altpm->u.arr;
bin_unset:Src/builtin.c:3379: if (start < arrlen(vbuf.pm->u.arr)) {
restore_params:Src/exec.c:3898: tpm->gsu.a->setfn(tpm, pm->u.arr);
copyparam:Src/params.c:1028: tpm->u.arr = zarrdup(pm->gsu.a->getfn(pm));
arrgetfn:Src/params.c:3341: return pm->u.arr ? pm->u.arr : &nullarray;
arrsetfn:Src/params.c:3350: if (pm->u.arr && pm->u.arr != x)
arrsetfn:Src/params.c:3351: freearray(pm->u.arr);
arrsetfn:Src/params.c:3354: pm->u.arr = x;
scanendscope:Src/params.c:5096: pm->gsu.a->setfn(pm, tpm->u.arr);
paramsubst:Src/subst.c:2499: pm->u.arr = aval;
prev parent reply other threads:[~2015-12-03 23:36 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-27 7:37 Daniel Shahaf
2015-11-27 8:26 ` Mikael Magnusson
2015-11-27 10:59 ` Bart Schaefer
2015-11-28 18:05 ` Daniel Shahaf
2015-11-28 19:36 ` Peter Stephenson
2015-11-30 3:20 ` Daniel Shahaf
2015-12-03 23:36 ` Daniel Shahaf [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151203233604.GD1955@tarsus.local2 \
--to=d.s@daniel.shahaf.name \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).