zsh-workers
 help / color / mirror / code / Atom feed
From: Sebastian Gniazdowski <sgniazdowski@gmail.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: mmap on OS X
Date: Wed, 28 Oct 2015 11:02:07 +0100	[thread overview]
Message-ID: <CAKc7PVDzrnBaMUK=MDFbaaEGBaVSONM+gPbdmbMH0O0KVFgrVA@mail.gmail.com> (raw)
In-Reply-To: <CAKc7PVBK5J5xBvm0t1mpwwax0FbivOw+nWbLBihcph0+WxW3zw@mail.gmail.com>

PS. The result:

...
Running [zsh-first-mmap]:                 string_test     127042,96
Running [zsh-before-first-mmap]:      string_test      75629,60

Shows that mmap is not necessarily "faster for big data". It is safer
to say that in combination with recent optimizations mmap is
beneficial.

Best regards,
Sebastian Gniazdowski


On 28 October 2015 at 10:49, Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> Hello,
> the patch 1f62d8d (34451) introduced mmap on OS X. This caused a
> slowdown which I and Bart identified. Then the patch has been recently
> reverted with 8934007 (36956), however before that a few optimizations
> have been introduced. It turned out that they smoothed out effect of
> 34451. Starting from 9f8e3e8 (36834) mmap was no longer slowing things
> down. I also checked the update of 36834, which is patch 506d592
> (36943), and it's the same.
>
> With the patch reverted the situation is as follows:
> - for small data there is no change
> - for large data reverted version is slower
>
> So the whole thing is like this:
> - OS X mmap is slower for smaller data
> - recent optimizations smooth this out
> - OS X mmap is faster for large data
>
> So by restoring mmap use we have all cases covered and full performance.
>
>
> Results for big data (max string size 1350000):
> *Running [zsh-withmmap]:                  string_test      57625,00
> Running [zsh-withoutmmap]:             string_test      85235,24
> Running [zsh-first-mmap]:                 string_test     127042,96
> Running [zsh-before-first-mmap]:      string_test      75629,60
>
> Results for small data (max string size 225000):
> Running [zsh-withmmap]:                  string_test       1496,85
> Running [zsh-withoutmmap]:             string_test       1595,89
> **Running [zsh-first-mmap]:                 string_test       3790,70
> Running [zsh-before-first-mmap]:      string_test       1496,02
>
> It can be seen that for small data the slowdown of ** is smoothed out
> in recent Zsh, while for large data mmap in recent Zsh gives speed up
> (*).
>
> Best regards,
> Sebastian Gniazdowski


      reply	other threads:[~2015-10-28 10:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-28  9:49 Sebastian Gniazdowski
2015-10-28 10:02 ` Sebastian Gniazdowski [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='CAKc7PVDzrnBaMUK=MDFbaaEGBaVSONM+gPbdmbMH0O0KVFgrVA@mail.gmail.com' \
    --to=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).