Swift-laajennusten vertailukohta vs. menetelmät: Swift 4.1 (toukokuu 2018)

Interaktiiviset kaaviot ovat saatavilla täältä: http://minikin.me/extensions

Motivaatio

Muutama viikko sitten keskustelin iOS-ohjelmoijan kanssa, jolla on monia vahvoja uskomuksia. Yksi niistä kuulostaa: "Swift-laajennusten käyttö on erittäin huono käytäntö, koska kokoamisajat kasvavat dramaattisesti ja heikentävät luettavuutta ja koodin selkeyttä". En aio arvioida luettavuudesta ja selkeydestä. Ne ovat henkilökohtaisia ​​tyyliasetuksia, mutta olin hyvin hämmentynyt kokoamisaikaa koskevasta väitteestä. Muistan, että aiheesta oli keskusteltu vähintään kolme vuotta sitten. Kolme vuotta Swiftille kuulostaa minulta, kuten 50 vuotta ihmiskunnalla. Olin melko varma, että tilanne ei ole niin paha kuin tämä ihminen ajattelee, koska tiedän, että Swift-tiimi parantaa jatkuvasti kieltä, mukaan lukien kokoamisaika. En ole sellainen henkilö, joka aikoo riitauttaa ilman vakavia perusteluja.

Benchmarking

Viime viikonloppuna minulla oli muutama tunti vapaata tarkistaa hänen lausuntonsa. Kirjoitin ruby-skriptin tarkistaaksesi laajennusten ja menetelmien suorituskyvyn. Valitsemani lähestymistapa on melko yksinkertainen, luultavasti jopa naiivi, mutta haluaisin kuitenkin nähdä tuloksia. Tarkistin seuraavat tapaukset:

  • Luokka + menetelmät
  • Luokka + laajennukset
  • Struct + -menetelmät
  • Struct + laajennukset

Ruby-skripti luo n numerofunktiota jokaiselle tapaukselle (esimerkissä n = 3):

Luokka + menetelmät

luokka MyClass {
    olkoon n = 1000
    func method_1 () {
      kohteelle kohdassa 0 .. 

Luokka + laajennukset

luokka MyClass {
    olkoon n = 1000
    func method_1 () {
      kohteelle kohdassa 0 .. 

Halusin myös tietää vastauksen kysymykseen: Kuinka monta laajennusta on reaalimaailman Swift-sovelluksissa? Tarkistin suosituimmat avoimen lähdekoodin sovellukset, jotka on kirjoitettu Swift-muodossa, ja muutama sovellus, jonka olemme kehittäneet yrityksessämme asiakkaille useille laajennuksille.

Testien suorittamiseksi aseta USE_EXTENSIONS arvoksi true tai false Rakefilessa.

Suorita testit:

rake benchmark

Siivoustestien tulokset:

rake puhdas

Tulokset

Kun oli kyse edustaa kerättyjä tietoja selkeästi ja tarkoituksenmukaisesti, tietojenkäsittelytaitoni olivat varsin käteviä. Loin python-komentosarjan main.py, joka tuottaa bokeh-kaavioita.

Interaktiiviset kaaviot ovat saatavilla täältä: http://minikin.me/extensions

Testausympäristö: macOS 10.13.4, Swift 4.1, 2016 MacBook Pro, 2,6 GHz Intel Core i7, 16 Gt 2133 MHz LPDDR3

Päätelmät

Keskimäärin menetelmälähestymistapa on välillä -6% - 70% yhtä nopeasti kuin vastaava toteutus laajennuksilla.

Mutta tarkoittaako tämä, että meidän ei pitäisi käyttää laajennuksia? Luultavasti ei.
Oikeissa sovelluksissa pidennysten määrä nousee harvoin 1 000: een, ja jos näin on, ero on noin 20%.

Toki, todellisessa sovelluksessa meillä on erilaisia ​​tuloksia, mutta absoluuttisella aikaerolla mitattuna säästöt eivät todennäköisesti ole merkittäviä useimmissa olosuhteissa.

Jos haluat kokeilla, voit tarkistaa repon GitHubista.

Jos sinulla on kysyttävää, ota rohkeasti yhteyttä minuun: @minikin

Päivitys 1 (03.06.2018):

Yarik Arsenkin pyysi minua lisäämään vertailuarvon tapausluokan + yksityiset toiminnot laajennuksessa vs. luokka + yksityisissä menetelmissä. Tarkista päivitetyt kaaviot ja tulokset.