zsh-workers
 help / color / mirror / code / Atom feed
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;


      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).