A Swift kiterjesztések összehasonlító módszere: Swift 4.1 (2018. május)

Az interaktív táblázatok itt érhetők el: http://minikin.me/extensions

‍ Motiváció

Néhány héttel ezelőtt vitatkoztam egy iOS programozóval, aki sok erős meggyőződéssel rendelkezik. Az egyik így hangzik: „A Swift kiterjesztések használata nagyon rossz gyakorlat, mivel a fordítási idő drámaian növekszik, és csökkenti az olvashatóságot és a kód egyértelműségét”. Nem fogom megítélni az olvashatóságról és az érthetőségről. Ezek személyes stíluspreferenciák, de nagyon össze voltam zavarodva az összeállítási idő érvelésével. Emlékszem, hogy három vagy több évvel ezelőtt vita folyt a témáról. Három év Swift számára számomra szól, mint az 50 év az emberiség számára. Nagyon biztos voltam benne, hogy a helyzet nem olyan rossz, mint ez az ember gondolja, mert tudom, hogy a Swift csapat folyamatosan javítja a nyelvet, ideértve a fordítási időt is. Nem vagyok olyan ember, aki szilárd érvelés nélkül fog vitatkozni.

Benchmarking

A múlt hétvégén néhány órát szabadon ellenőriztem a nyilatkozatát. Ruby szkriptet írtam a kiterjesztések és a módszerek teljesítményének ellenőrzésére. A választott megközelítés nagyon egyszerű, valószínűleg naiv is, de egyébként szeretnék látni néhány eredményt. A következő eseteket ellenőriztem:

  • Osztály + módszerek
  • Osztály + kiterjesztések
  • Struct + módszerek
  • Struct + kiterjesztések

A Ruby szkript mindegyik esethez n számfüggvényt hoz létre (n = 3 példában):

Osztály + módszerek

osztály MyClass {
    legyen n = 1000
    func method_1 () {
      a 0-ban lévő tételnél. 

Osztály + kiterjesztések

osztály MyClass {
    legyen n = 1000
    func method_1 () {
      a 0-ban lévő tételnél. 

Azt is meg akartam tudni a választ a kérdésre: hány kiterjesztés van a valós SWIFT alkalmazásokban? Ellenőriztem a legnépszerűbb, nyílt forráskódú, Swift-ben írt alkalmazásokat és néhány olyan alkalmazást, amelyeket számos kiterjesztéshez fejlesztettünk ki cégünkben az ügyfelek számára.

A tesztek futtatásához állítsa az USE_EXTENSIONS értékét igazra vagy hamisra a Rakefile fájlban.

Tesztek futtatása:

rake benchmark

Tisztítási tesztek eredménye:

rake tiszta

Eredmények

Amikor a gyűjtött adatokat egyértelmű és értelmes módon kellett reprezentálni, az adattudományi ismereteim nagyon hasznosak voltak. Készítettem egy python parancsfájlt, a main.py-t, amely bokeh-diagramokat generál.

Az interaktív táblázatok itt érhetők el: http://minikin.me/extensions

Tesztelési környezet: macOS 10.13.4, Swift 4.1, 2016 MacBook Pro, 2.6 GHz Intel Core i7, 16 GB 2133 MHz LPDDR3

Következtetések

A módszertan megközelítése átlagosan -6% - 70% között van, olyan gyors, mint a kiterjesztésekkel egyenértékű megvalósítás.

De ez azt jelenti, hogy nem szabad használni a bővítményeket? Valószínűleg nem.
A valódi alkalmazásokban a kiterjesztések száma ritkán eléri az 1000-et, és ha igen, akkor a különbség körülbelül 20%.

Persze, egy valódi alkalmazásban eltérő eredményeket fogunk kapni, de abszolút időeltolódással mérve, a megtakarítások valószínűleg a legtöbb esetben nem észlelhetők.

Ha kísérletezni szeretne, ellenőrizze a repót a GitHubon.

Ha bármilyen kérdése van, kérjük, bátran forduljon hozzám: @minikin

1. frissítés (2018.06.03.):

Yarik Arsenkin arra kért, hogy adjak hozzá referenciaértéket az osztály + privát funkciókhoz a kiterjesztés vs. osztály + privát módszerek esetében. Kérjük, ellenőrizze a frissített táblázatokat és eredményeket.