6
bahua
2y

I got my new(to me) MacBook Pro last week, provided by work. I've got all my setup and config done, for the most part, and I've noticed something.

Performance is shit. Has anyone else noticed this about the 2017 and later models? The 2015 model I had before was much, much smoother. Just zooming windows, a previously butter-smooth experience, is noticeably choppy. I/O performance is garbage too. I have a small iotest script that just writes a string a couple hundred times to disk, deletes it, and repeats this activity 100,000 times. On my Linux machine at home with six year old hardware, this takes about three seconds. On my new system76 laptop it takes just over a second. On the 2017 MacBook Pro, it takes about forty seconds.

The 2017 and 2018 models are a direct downgrade in performance. Why isn't anyone talking about this?

Comments
  • 1
    Mind sharing that script?
  • 0
    @ganjaman

    Not at all. I'll try to remember to post it when we get the boy down for his nap in about three hours.
  • 0
    Tbh that sucks. But hey its apple its surely the best hardware for that price right ? Right ? 😂😂😂😂😂😂😂
  • 1
    I have a 2018 MBP 13” and I’m loving it.

    I didn’t go for the 15 as the lowest one is pricier and less performant than the mid 13.

    Admittedly it could do with a tad more punch sometimes, but that’s not unexpected, I didn’t get the best spec.

    But, it’ll happily run a win 10 vm flawlessly over 2 monitors at native res and barely ever skips a beat.
  • 2
    MBPs are terribly overpriced but this is still not expected. Especially the SSDs in them are supposed to be very fast. Maybe there's something wrong with your particular machine?
  • 0
    Maybe the meltdown fixes affect how your script runs?
  • 1
    @ganjaman

    https://pastebin.com/8zBys2WZ

    Warning, it's perl, because perl is great.
  • 2
    All hate apple! For a better world!
    anyway...
    may it be because of the journaling? You are never syncing the file system between writes.
    MAYBE this script on a ext4 disk never write to it, because at the end you always remove the file...
    maybe apple has no journaling (ah! Looser) and is the only one (in your test) that actually use the disk
  • 1
    @bahua I ran the script on an otherwise perfectly working MBP 2017 and it took more than 20 seconds. On my Linux desktop, it took a little more than a second on a __HDD__. Interesting! I ran disk benchmarks, wrote and read huge files onto the MBP's SSD and it worked as expected with read and write speeds at several hundred MB/s. The machine is snappy and everything else is working fine, except the script.One thing though, in your script the CPU is being more of a bottleneck than the IO and more time was being spent in syscalls rather than IO blocks, so one hunch I had is: maybe this is due to the different ways IO operations are implemented in the kernels. Maybe linux kernel's IO implementation uses fewer syscalls (or less overhead per syscall) than macOS's kernel? This is just a guess and actually testing this theory is beyond me :( so I hope someone else can get to the bottom of this :)
  • 2
    @bahua as @mngr said, you want to try to sync so that anything is actually written on disk. Close only flushes.

    I lol'd at the following note on metacpan.org:
    Calling sync() too often on a multi-user system is slightly antisocial.
  • 2
    Apple's main selling point: it's much more expensive than the competition...
Add Comment