[webkit-dev] Tip: Use 64-bit git binaries on Mac OS X

Mihai Parparita mihaip at chromium.org
Thu Dec 9 16:42:01 PST 2010


Update: The maintainer of the binaries
http://code.google.com/p/git-osx-installer/ has agreed to provide both i386
and x86_64 installers now (and has uploaded builds of 1.7.3.3 with both), so
hopefully it should be easier to get the latter now.

Mihai

On Thu, Dec 9, 2010 at 3:43 AM, Jeremy Orlow <jorlow at chromium.org> wrote:

> For what it's worth, on my 12GB of ram mac pro:
>
> $ sudo sysctl -w kern.maxvnodes=384000
> kern.maxvnodes: 197632 -> 384000
>
> Took times from 2.11-2.06 down to 2.05-2.02.  I.e. it made a small
> difference, but not much.  The 64 bit patch definitely seemed to help, but I
> didn't think to time before and after.
>
> J
>
> On Wed, Dec 8, 2010 at 11:38 PM, Eric Seidel <eric at webkit.org> wrote:
>
>> Mark Rowe pointed out to me over IRC that the real problem is we're
>> blowing out the vnode cache.
>>
>> Even on an 8GB machine, the default cache is too small for all of
>> WebKit to fit in it.
>>
>> On my 4GB machine (and on Mark's 8GB) we tried incrementing the cache
>> to 384000 (the 4GB default is 64512 and the 8GB default is 128000).
>>
>> My git status times dropped again by over 50% to 2.6 seconds! (still
>> an eternity compared to a linux machine of course...)
>>
>> If you'd like to play around with this, you can set your vnode cache limit
>> with:
>> sudo sysctl -w kern.maxvnodes=384000
>>
>> You can read it with:
>> sysctl kern.maxvnodes
>>
>> You can test to see if the cache is large enough by trying:
>> git status; time git status
>>
>> the second one should be very fast if your cache is large enough.
>>
>> I don't know what the exact right trade-off is.  I believe the vnode
>> cache uses wired memory (which is a limited resource!).  As far as I
>> can tell you can't decrease the cache max w/o rebooting.  sysctl will
>> set it, but setting it to a smaller number seems to have not effect.
>>
>> I don't know how to make the setting last across reboots.  Mark
>> mentioned that putting the setting in /etc/sysctl.conf should work,
>> but that at least for his machine that didn't seem to have any effect
>> for this particular setting.
>>
>> That's what I know.
>>
>> -eric
>>
>>
>> On Wed, Dec 8, 2010 at 3:02 PM, Eric Seidel <eric at webkit.org> wrote:
>> >
>> > FYI, my git status runs on my Mac Book Pro were an average of 9.2
>> seconds (git version 1.7.1, git-osx-installer) before installing Mihai's
>> 64bit build (git version 1.7.3.3), and were 6.0 seconds after.
>> > -eric
>> >
>> > On Wed, Dec 8, 2010 at 2:20 PM, Eric Seidel <eric at webkit.org> wrote:
>> >>
>> >> I've posted a patch to make webkit-patch warn users when they're on a
>> 64-bit system with a 32-bit git:
>> >> https://bugs.webkit.org/show_bug.cgi?id=50715
>> >> 4 seconds on every git status is huge.  webkit-patch upload has to run
>> at least 3 git status commands (due to expecting files to change on disk
>> during operation), so this means a savings of 12 seconds on your machine!
>> >> -eric
>> >> On Tue, Dec 7, 2010 at 4:04 PM, Mihai Parparita <mihaip at chromium.org>
>> wrote:
>> >>>
>> >>> After complaining to a Linux-using friend for the n-th time that "git
>> >>> status" was much slower on my Snow Leopard machine than on his Linux
>> >>> box, I decided to look into why this is. As it turns out, most people
>> >>> get git binaries from http://code.google.com/p/git-osx-installer/,
>> >>> which are 32-bit. Switching to 64-bit binaries made git status go from
>> >>> 6.58s to 2.50s (mainly because this does fewer mmaps).
>> >>>
>> >>> You can download a 64-bit binary installer from
>> >>>
>> https://github.com/downloads/mihaip/git_osx_installer/git-1.7.3.3-intel-x86_64-leopard.dmg
>> ,
>> >>> or you can build it yourself (more details at
>> >>>
>> http://blog.persistent.info/2010/12/making-git-faster-on-large-repositories.html
>> ).
>> >>>
>> >>> Mihai
>> >>> _______________________________________________
>> >>> webkit-dev mailing list
>> >>> webkit-dev at lists.webkit.org
>> >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >>
>> >
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101209/86d5cf3f/attachment.html>


More information about the webkit-dev mailing list