From: Bart Schaefer <schaefer@brasslantern.com>
To: Sebastian Gniazdowski <sgniazdowski@gmail.com>, zsh-workers@zsh.org
Subject: Re: Slowdown around 5.0.5-dev-0
Date: Fri, 23 Oct 2015 12:26:55 -0700 [thread overview]
Message-ID: <151023122655.ZM21177@torch.brasslantern.com> (raw)
In-Reply-To: <CAKc7PVBC+MPN+EaRQni89PCH-AJk0X40wu5+eP1P3vqQhG6w7g@mail.gmail.com>
In-Reply-To: <CAKc7PVDR5P6d==FbL_yP3rzDxHO1FGt=EZh1jT3jBs74TPZbOw@mail.gmail.com>
On Oct 23, 8:32am, Sebastian Gniazdowski wrote:
} Subject: Re: Slowdown around 5.0.5-dev-0
}
}
} [ text/plain
} Encoded with "quoted-printable" ] :
}
} I ran the performance tests again with script formatting them
} differently - they are aggregated on test function, not on zsh
} version. This allows easier interpretation. A new conclusion is that
} zhalloc patch doesn't help for string_test. So the first patch (36834)
} speeds up string operations and also introduces increased memory
} usage.
Thanks for the patch. I think you've removed too much; the part about
finding the arena with the most space rather than first arena with any
space should have stayed, as should the changes to zhalloc() that were
included in 36834.
Try the below patch against 8e9a68ad1 ?
On Oct 23, 5:57pm, Sebastian Gniazdowski wrote:
} Subject: Re: Slowdown around 5.0.5-dev-0
}
} On 23 October 2015 at 17:40, Sebastian Gniazdowski
} <sgniazdowski@gmail.com> wrote:
} > I attach the patch that withdraws 9f8e3e8 and 643aca9 (which are 36834)
}
} One note is that 643aca9 isn't fully from 36834 because:
} if (fheap == h)
} fheap = NULL;
}
} Is moved to top of "if (h->next) {". Was this intended?
Yes it was, but irrelevant since that whole block is being backed out.
diff --git a/Src/mem.c b/Src/mem.c
index 68bd767..15d8fd2 100644
--- a/Src/mem.c
+++ b/Src/mem.c
@@ -294,7 +294,7 @@ pushheap(void)
#endif
for (h = heaps; h; h = h->next) {
- DPUTS(!h->used && h->next, "BUG: empty heap");
+ DPUTS(!h->used, "BUG: empty heap");
hs = (Heapstack) zalloc(sizeof(*hs));
hs->next = h->sp;
h->sp = hs;
@@ -339,10 +339,12 @@ freeheap(void)
* of stuff already on the heap, this is an enormous amount of work,
* and performance goes to hell.
*
- * Therefore, we defer freeing the most recently allocated arena until
- * we reach popheap(). This may fail to reclaim some space in earlier
- * arenas.
- *
+ * However, if the arena to which fheap points is unused, we want to
+ * free it, so we have no choice but to do the sweep for a new fheap.
+ */
+ if (fheap && !fheap->sp)
+ fheap = NULL; /* We used to do this unconditionally */
+ /*
* In other cases, either fheap is already correct, or it has never
* been set and this loop will do it, or it'll be reset from scratch
* on the next popheap(). So all that's needed here is to pick up
@@ -386,26 +388,6 @@ freeheap(void)
VALGRIND_MEMPOOL_TRIM((char *)h, (char *)arena(h), h->used);
#endif
} else {
- if (fheap == h)
- fheap = NULL;
- if (h->next) {
- /* We want to cut this out of the arena list if we can */
- if (h == heaps)
- hl = heaps = h->next;
- else if (hl && hl->next == h)
- hl->next = h->next;
- else {
- DPUTS(hl, "hl->next != h when freeing");
- hl = h;
- continue;
- }
- h->next = NULL;
- } else {
- /* Leave an empty arena at the end until popped */
- h->used = 0;
- fheap = hl = h;
- break;
- }
#ifdef USE_MMAP
munmap((void *) h, h->size);
#else
@@ -473,19 +455,6 @@ popheap(void)
hl = h;
} else {
- if (h->next) {
- /* We want to cut this out of the arena list if we can */
- if (h == heaps)
- hl = heaps = h->next;
- else if (hl && hl->next == h)
- hl->next = h->next;
- else {
- DPUTS(hl, "hl->next != h when popping");
- hl = h;
- continue;
- }
- h->next = NULL;
- }
#ifdef USE_MMAP
munmap((void *) h, h->size);
#else
next prev parent reply other threads:[~2015-10-23 19:26 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-10 10:54 Sebastian Gniazdowski
2015-10-10 17:58 ` Bart Schaefer
2015-10-10 18:11 ` Sebastian Gniazdowski
2015-10-10 18:32 ` Sebastian Gniazdowski
2015-10-11 0:06 ` Bart Schaefer
2015-10-11 6:20 ` Bart Schaefer
2015-10-11 8:39 ` Sebastian Gniazdowski
2015-10-11 16:17 ` Bart Schaefer
2015-10-11 16:48 ` Sebastian Gniazdowski
2015-10-11 17:31 ` Bart Schaefer
2015-10-11 18:05 ` Sebastian Gniazdowski
2015-10-11 21:22 ` Bart Schaefer
2015-10-12 8:21 ` Sebastian Gniazdowski
2015-10-12 14:01 ` Bart Schaefer
2015-10-12 16:50 ` Sebastian Gniazdowski
2015-10-13 0:33 ` Bart Schaefer
2015-10-13 8:21 ` Sebastian Gniazdowski
2015-10-13 15:52 ` Bart Schaefer
2015-10-14 6:50 ` Sebastian Gniazdowski
2015-10-14 13:27 ` Peter Stephenson
2015-10-14 16:25 ` Bart Schaefer
2015-10-14 16:50 ` Bart Schaefer
2015-10-15 4:32 ` Bart Schaefer
2015-10-15 13:03 ` Sebastian Gniazdowski
2015-10-16 0:35 ` Bart Schaefer
2015-10-17 9:12 ` Sebastian Gniazdowski
2015-10-17 9:24 ` Sebastian Gniazdowski
2015-10-18 16:19 ` Bart Schaefer
2015-10-18 20:40 ` Sebastian Gniazdowski
2015-10-18 21:07 ` Bart Schaefer
2015-10-18 21:31 ` Sebastian Gniazdowski
2015-10-19 17:21 ` Bart Schaefer
2015-10-22 12:49 ` Sebastian Gniazdowski
2015-10-22 15:00 ` Bart Schaefer
2015-10-22 16:28 ` Sebastian Gniazdowski
2015-10-22 16:33 ` Sebastian Gniazdowski
2015-10-23 15:40 ` Sebastian Gniazdowski
2015-10-23 15:57 ` Sebastian Gniazdowski
2015-10-23 19:26 ` Bart Schaefer [this message]
2015-10-23 23:50 ` Bart Schaefer
2015-10-24 6:09 ` Sebastian Gniazdowski
2015-10-24 7:37 ` Sebastian Gniazdowski
2015-10-24 8:04 ` Sebastian Gniazdowski
2015-10-24 19:39 ` Bart Schaefer
2015-10-25 7:35 ` Sebastian Gniazdowski
2015-10-25 17:23 ` Bart Schaefer
2015-10-25 20:56 ` Sebastian Gniazdowski
2015-10-26 0:49 ` Bart Schaefer
2015-10-26 7:41 ` Sebastian Gniazdowski
2015-10-26 7:47 ` Sebastian Gniazdowski
2015-10-24 6:27 ` Sebastian Gniazdowski
2015-10-24 10:54 ` Sebastian Gniazdowski
2015-10-24 11:25 ` Sebastian Gniazdowski
2015-10-24 16:31 ` Bart Schaefer
2015-10-24 16:41 ` Bart Schaefer
2015-10-23 6:32 ` Sebastian Gniazdowski
2015-10-16 0:37 ` Bart Schaefer
2015-10-13 13:07 ` Sebastian Gniazdowski
2015-10-13 13:31 ` Sebastian Gniazdowski
2015-10-12 12:05 ` Sebastian Gniazdowski
2015-10-12 15:13 ` Bart Schaefer
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=151023122655.ZM21177@torch.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=sgniazdowski@gmail.com \
--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).