{"id":38011,"date":"2022-12-29T16:38:40","date_gmt":"2022-12-29T21:38:40","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=38011"},"modified":"2022-12-29T19:55:47","modified_gmt":"2022-12-30T00:55:47","slug":"its-often-memory-thats-killing-your-performance","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/12\/29\/its-often-memory-thats-killing-your-performance\/","title":{"rendered":"It’s Often Memory That’s Killing Your Performance"},"content":{"rendered":"

Rob Napier<\/a>:<\/p>\n

\n

My first mistake was trying to make it parallel before I pulled out Instruments. Always start by profiling. Do not make systems parallel before you’ve optimized them serially. Sure enough, the biggest bottleneck was random number generation.<\/p>\n

[…]<\/p>\n

Huge amounts of time were spent in retain\/release. Since there are no classes in this program, that might surprise you, but copy-on-write is implemented with internal classes, and that means ARC, and ARC means locks, and highly contended locks are the enemy of parallelism.<\/p>\n

[…]<\/p>\n

I rewrote update<\/code> and all the other methods to take two integer parameters rather than one object parameter and cut my time down to 9 seconds [from 40].<\/p>\n<\/blockquote>\n\n

Steve Canon<\/a>:<\/p>\n

\n

pet peeve: using “big-O” to refer to abstract algorithmic complexity. Big-O is the technique of looking at the leading term and ignoring constant factors. It is usually the right tool to analyze memory use or cache misses as well!<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n