Új hozzászólás Aktív témák

• #15606 martonx veterán pmonitor #15603

  Új Válasz 2021-02-28 18:00:22 #15606

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz pmonitor #15603 üzenetére

  Nem off topik ez. Csak egyszerűen nem kell butaságokat írni. Annak, hogy egy programnyelv jó-e vagy rossz, egy csomó szempontja lehet, nem csak a futásidőben nyújtott teljesítmény. Hiszen, ha így lenne, akkor nem lenne feljövőben a Python, a PHP már vagy egy évtizede ki kellett volna, hogy haljon, a javascriptről nem is beszélve

  Ugyanakkor nyilván azt se lehet kijelenteni, hogy nem számít a futásidejű teljesítmény, mert igenis van sok olyan eset, amikor meg erre kell kihegyezni valamit. De ekkor is több mindent figyelembe kell venni. Pl. van-e értelme natív nyelvben újraírni valamit, csak azért, hogy pár százalék gyorsulást hozzon a konyhára? Vagy inkább egyszerűbb egy szerver alá betolni plusz két processzormagot, és a fejlesztők meg a hónapokig / évekig tartó újraírás (nem is beszélve egy új nyelv megtanulásáról) helyett inkább olyan új feature-ökön dolgozhatnának, amikkel megtöbbszörözik a cég bevételeit?
  Vagy említetted, hogy pl. elég csak a teljesítmény kritikus részeket megírni natív kódban, és azokat dll-ként behivatkozni. Ekkor vajon mennyire fog jól működni a közös logolás, monitoring? Mennyire lesz fájdalmas CI/CD rendszert több repository-ból kiindulva felépíteni, és egy sikeres build/deploy/testing fázist végig verni az X féle nyelven készült komponensken? Mekkora szopás van ebben az esetben, ha akár csak egy szerver frissítéskor eltörik valamelyik ilyen "külső" komponens? Netán linuxról windowsra váltanak vagy vissza? Vagy csak 32-ről 64 bitre? És máris cseszhetik a dll komponensüket. Ráadásul mi van, ha az a kolléga már nincs is a cégnél, aki ezt anno készítette?
  És még hosszasan lehetne sorolni a kismillió szempontot, amiket fejlesztéskor számításba kell venni. Ahelyett, hogy csak az lebegne a fejlesztők szeme előtt, hogy hú, használjuk pont azt a nyelvet, amivel most éppen 50% teljesítmény növekedést lehetne elérni.

  Én is dolgoztam olyan projekten, ahol a futásidő kritikus volt. Nálunk C# projektnél az volt a mondás, hogy 5 másodperc alatt kell kiszolgálni egy HTTP requestet (kellemesen bonyolult háttér logikákat futtatva több millió adatsoron), mert az előző PHP-s csapat ezt se tudta felülről még csak megközelíteni se. Nálunk ez végül 40-80ms között szórt. Vajon elégedettebb lett volna-e a megrendelőnk, ha mindezt C-ben oldja meg egy másik csapat mondjuk négyszer ennyi fejlesztési időből, és a végén 30-60ms a requestek válaszideje? Miközben ő csak annyit akart, hogy 5 másodpercen belül menjenek a válaszok.

  Szóval a világ korántsem olyan fekete-fehér, mint ahogy te látod.

• #15604 kovisoft őstag pmonitor #15603

  Új Válasz 2021-02-28 11:04:40 #15604

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  kovisoft

  őstag

  válasz pmonitor #15603 üzenetére

  Nem gondolnám off topicnak a témát, bármit meg lehet értelmesen vitatni, de ha valaki úgy kezdi, hogy ez meg az milyen sz@r, ezek meg azok milyen hülyék, stb, akkor azzal óhatatlanul belegázol valaki másnak a lelkébe, aztán nem győznek takarítani a modik.

  Az adott feladat és a rendelkezésre álló erőforrások döntik el, hogy elfogadható-e ez a futásidő vagy nem. Sokszor elfogadható, máskor meg nem. Ha nem elfogadható, akkor valahogy gyorsítani kell a programot, és ennek többféle módja is lehetséges, nem csak a váltás egy másik programnyelvre, pláne ha több millió soros kódbázisról van szó. Első körben nyilván az ember az adott programnyelven az adott programrészt próbálja optimalizálni (pl. gyorsabb algoritmusok használata, heurisztikák beépítése, caching, párhuzamosítás, stb). Bizonyos esetekben lehet hardvert bővíteni vagy nagyobb teljesítményűre cserélni. Nyilván szóba jöhet a kódnak vagy egy részének egy másik programnyelvre való átültetése is, de mit csináljon pl. az, aki már eleve C-ben (vagy akár Assemblyben) oldotta meg a feladatot, és még így is lassú?

  Aztán meg olyan is van, hogy ugyan tudnánk gyorsítani a kódon, de ez túl nagy munka lenne és sokba kerülne a cégnek vagy a megrendelőnek, és így máris elfogadhatóvá válik a hosszabb futásidő.

Új hozzászólás Aktív témák