Rixstep
 About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Learning Curve » Developers Workshop

Through a Dark Glass with Tim

The climb up the High Sierra is treacherous.


Get It

Try It

LONDON (Rixstep) — The road to perfection is treacherous. One must continually be grateful for the crumbs that fall off the table. Not to mix metaphors.

High Sierra was a big question mark, after the stellar performance of almost every version of OS X before that, but APFS lured. Then came the crash-prone Xcode 9.2, and it was time to take a closer look.

That Xcode regularly crashes is neither new nor an encumbrance, as all we want is the underlying LLVM compiler - which, for years, had been horrendous.

But lo and behold - this one actually works! And works better!

One fondly remembers the good old days at Microsoft when the pinheads in Redmond still hadn't realised that less code means better performance. Then Dave got involved, swatted a few heads, and things were soon as right as rain again.

One can't know what went wrong in Cupertino, although many are tempted to draw Swift conclusions.

[For those who don't know, 'Swift' is a new (but incomplete) programming language devised by Apple, best described as 'Objective-C for kids'. Ed.]

A previous article touched on the discovery:

http://rixstep.com/2/2/20171203,00.shtml

Note how binary sizes skyrocket at the time of the introduction of Apple's darling language.

TargetBinaryTargetBinary
10.67070410.1062276
10.77070410.1150444
10.87066810.1250444
10.96227610.1350444

Note as well how they go down again several years (five point OS versions) later. Cause for celebration?

Good code is always welcome. Therefore a Gibraltar effort at Rixstep to hop on the bandwagon - and, simultaneously, clear out the flotsam and jetsam.

Xfile!

The anomaly described at the above link was finally resolved. No, the app could not be built on 10.13: Apple's new fonts and sundry funky behaviour were too much.

The same holds for any app using NSBrowser cells to accommodate images. Such products have to be built on a much older system. Thanks, Tim, for keeping an eye on things.

But at least they're blazingly fast. Xfile and its friends are no longer 'one bounce launches' - they're instantaneous.

[Don't forget that the ACP is built to minimise access to secondary storage. All image files, for example, aren't even real image files anyway, and loaded once and only once for the entire 100+ app arsenal. Ed.]

Time to look through the rest of the arsenal.

'106'

All told, 106 apps in the ACP (AppleCore Project) were updated in a week, with almost perfect results. Opening and re-saving NIBs automatically converts file formats and eliminates outdated files. (Just be sure to have a backup - IB won't do that for you.)

And it's time for legacy 32-bit apps to shape up or hit the road. The ACP lost half a dozen - three Cocoa, three command-line. (They might be back later.)

The increase in efficiency is palatable. Here the listing for Cocoa apps.

AppNowPrevAppNowPrevAppNowPrev
ASM1854018788MD1912819360Swap1431614580
ASMX4118445496NSURL88409024Swapwatch1453614696
BBC1443218808PlistEdit1400814248TIFFCompress1398814268
Bundle1397218300PlistTool1388814144Tracker5017254508
CatInfo2308427412Pwgen1385614096UCS1381618192
Chex1826018516Rixcomp1927623636Undercover2388029216
Classes1498019324Rixedit2313227468XaBatch2791228168
Clearff933613572Rixicons1380818152Xattr2385628184
Clipotheque4050044836Rixmode1869218948Xattrib1834018580
CRLF1814418392Rixstamp1912423404Xbase2747627732
FileInfo1874823084Rixtime1396814200Xframe5571659988
Forker1925219500Rorschach1482014884Xrename2283223096
Fortune940013704Royale1391614164Xsed1760817720
GD1879219040Runner1409214356Xshelf1915623516
GDE1879219040RxDefaults1874823084Xstat3237232620
Hawkeye3118431192S31318813444Xstrings2342023660
Luffarschack1866418920SPX2863228872XX1893223284
MC2148421600SPXN1430018652Zippit1874018996

The same holds for the command-line tools. Only the command-line version of CatInfo went the other way (by 36 bytes).

It's always nice when the compiler people get their act together. That's not to say the week wasn't an ordeal. Because it was.

[Remember the good old days? The ISVs begged Apple to make the dev tools open source so they could go in and fix the shit? You should. Ed.]

A few versions ago in the legacy of Project Builder Xcode, it suddenly became impossible to add external frameworks to a project. As if no one anywhere ever needed to do that. So one was forced to 'hack' the system. The hack was simple but lugubrious.

  1. Copy the framework into the project directory.
  2. Add the new copy of the framework to the project. (Then exit Xcode just in cases.)
  3. Create a symlink to the original framework, and have it replace the copy of the framework.
  4. Open trusty Xcode and build.

That this 'issue' should remain for so long is of course inexcusable, but things like that happen all the time with Apple's dev tools. What's enervating, however, is that when they finally get around to fixing things, each and every one of the 100+ project files has to be reconfigured - manually.

Fortunately, we have tools of our own (eg Xshelf) which can speed things up considerably. But even so.

The full list of updated apps and command-line tools is 106 in number. (107 if you count the ACP Framework.)

New Records!

Xfile and its friends set some new records. This is one of the nicest.

For those not mathematically inclined (what are you doing here) that means this many cells in 2/3 of a second.

Not bad?

[Xscan can expand the /Library hive, with ~8,600 directories and 32,792 file system items, in about a second and a half. Xfile expands the hive in less than a second. It's not about tricks and shortcuts, it's about doing it right. Ed.]

See Also
Wikipedia: LLVM
Wikipedia: Clang

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.