3 ms·
its not Crystals fault, but its disappointing that this kind of ad blocking is unavailable for 32bit devices, like iPhone 5/5c (and below).
by ratfacemcgee 11y ago
its not Crystals fault, but its disappointing that this kind of ad blocking is unavailable for 32bit devices, like iPhone 5/5c (and below).
- Doctor_Fegg 11y agoIndeed. I find it curious that it's not available for "performance reasons" - surely rendering an ad takes more CPU than blocking one?
- LoSboccacc 11y agoMaybe it refers to the RAM constraints more. They just call out the devices, but the actual constraint might or might not be the CPU on old devices new safari already struggle to keep in memory more than a couple tabs, so gut instinct points to memory being the issue.
- tdkl 11y agoYou can compile and sideload an open source content blocker on a 32bit device. But performance on some sites is slower then without blocking because of the regex performance difference, it's almost 50% slower. I'd quote the statement from a dev on reddit, but can't remember where it was.
- msephton 11y agowhat regex? content blocking compiles the source regex to byte code which is executed natively. the 32-bit hang up is because of performance of compiling the rules, not executing them.
- giovannibajo1 11y agoIt should be true, but the reality is that most ad blockers have such a complex ruleset to match that they can actually go slower and use more RAM than not running them. The graphs that uBlock shows are very compelling: https://github.com/chrisaljoudi/uBlock https://github.com/chrisaljoudi/uBlock I'm not saying that Apple tried hard enough; the content blockers on iOS are JIT-compiled to native ARM 64-bit code, so maybe they didn't have the codepath ready for 32-bit and/or they didn't bother. But it's surely not just a technical excuse.