Folyik a használaton kívüli kódok kidobálása a LibreOffice-ból

 ( trey | 2012. január 14., szombat - 16:37 )

Ismert, eltávolításra váró, nem használt metódusok a LibreOffice-ban

A LibreOffice egyik kellemetlen öröksége a gyakorlatilag mindenfelé heverő, nem használt kódok garmadája. A LibreOffice projekt azon dolgozik, hogy a Red Hat-os Caolan McNamara "callcatcher" eszközével összeszedje a használaton kívüli metódusokat. Ezeket a forrásfa gyökerében található unusedcode.easy fájlba gyűjtik eltávolítás céljából. A részletekről a Novell alkalmazásában álló Michael Meeks számol be itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Kiváncsi leszek azt elmondják-e, hogy hány kbájt-al csökkent a forrás és mennyivel a binárisok mérete ennek hatására. :)

hát igazából bárki meg tudná nézni :D de azért elég súlyos állapotban lehetett a kód vazz...


[ NeoCalc - Earnings Calculator for NeoBux ]

A Sun/Oracle semmit nem dobott ki. Biztos ti is ismertek olyan embereket, akik elteszik a rozsdás szögeket, mindenféle deszkákat stb., hogy "jó lesz az még valamire". :)

Igen, de pl a régi videokártyát nem a számítógépben tárolom, hanem a fiók mélyén.. :D

Software is like sex, it's better with a penguin. :D (r)(tm)(c) آكوش

*Normális* esetben a bináris mérete 0 byte-al, ha valóban nem használt kódról van szó.

----------------
Lvl86 Troll

Ez csak statikusan linkelt kodra igaz. A legtobb bizonyos meretnel nagyobb prgram nem ilyen.

Ezt nehéz megmondani, mert a logokból nem derül ki, és nemcsak ez van, hanem új feature-ök hozzáadása is. De pl. a Windows telepítő méretéről van grafikon. Az most 200 MB körüli az összes (~100) nyelvvel, a 3.3-nál ez még 255 MB volt. De ez nemcsak a kisebb kódnak köszönhető, sok más redundanciát is felszámoltunk. Ami pedig a fordítandó stringek számát illeti, az éppenséggel kevesebb a 3.5-nél, mint a 3.3-nál volt a sok új feature ellenére, mert kiderült, hogy egy csomó minden már sosem jelenik meg, és törölve lett ezért a kódból.

A kódtisztítás azonban nem merül ki az használaton kívüli metódusok törlésében, csak ezt könnyű demonstrálni, van hozzá eszköz (a callcatcher). Nagyon sok munka van abban is, hogy a saját osztályokat C++ standard osztályokra cseréljék, vagy pl. a sokféle string osztály közül kiválasztották a jobbakat, és a többit is arra kell áttenni. A másik terület a nem támogatott platformokra specifikus kódok kiirtása. Ilyenek például a Windows 3.1 (!), a Windows 9x, az OS/2, az OSF/1, de szerintem nemsokára erre a sorsra fog jutni a Solaris is. De a buildet készítő eszközökből is lehet jócskán irtani, több ezer sort töröltem az l10ntools modulból, pl. olyan fájlformátumok támogatását, amelyek már nagyon régóta nincsenek használatban.

Ettől gyorsulni fog, hogy kivágják a felesleget?

(minthogy kisebb lesz a kód szegmens, gyanítom, hogy rövidebb lesz az indulás).

nem használt függvényeket dobálnak ki, szóval a használatot nem érinti. ezzel maguknak szereznek jó nagy pirospontot, mert a fejlesztés, debugolás, tesztelés, stb. könnyebb lesz a sok sallang nélkül.


[ NeoCalc - Earnings Calculator for NeoBux ]

tényleg, igazad van, a szemetet a gcc is kivágja a fenébe az alapértelmezett optimalizációnál.

Egyszer deklaráltam egy változót, mindig növeltem eggyel, de nem olvastam sosem ki az értékét. A lefordított assemblyben nem volt benne.

Ebből a szempontból érdekes a kérdés, hogy megéri-e küzdeni a semmiért.

Hát tedd fel a kérdést magadnak: 10 000 vagy 15 000 sornyi kódot egyszerűbb karbantartani?


[ NeoCalc - Earnings Calculator for NeoBux ]

Tartottam már karban, lehet hogy nyuszi vagyok, de nem szoktam durr-bele bumm 52000 függvényt kitörölni, utána meg kitalálni, hogy vajon melyik hiányzik, amikor nem megy.

A wine fejlesztési modelljében egy ilyen patch azonnal a kukában landolna. Egyesével eltávolítod a függvényeket, ha nem megy visszavonod, csak így jutsz előre a wine repóban.

Lehet, hogy eltart egy évig is, de nem jut sosem olyan állapotba a kód, hogy fingod nincs éppen, hogy mi miért van.

Nem is úgy veszik ki, ha jól látom. Egyelőre gyűjtik csak...

Forditottal mar openoffice-t? ;)
___
info

Na te se tartottál még karban olyan projektet, amit évek óta fejlesztenek.

Van egy projektem, 3,5 éve foglalkozok vele. Jelenlegi terveink között szerepel, hogy tavasszal a kollégámmal nekiállunk és kikulizzuk az összes nem használt és duplikált kódot kikukázzuk, leginkább a karbantartás egyszerűsítése miatt.

Nagyon zavaró tud lenni, hogy ha át kell nézni valamit, akkor olyan kódokkal is foglalkozni kell, amelyek lehet, hogy évek óta nem használtak, mint ahogy az is zavaró tud lenni, hogyha kódduplikálás van (mert pl. egyik kolléga nem tudott arról, hogy a másik is megoldott egy problémát, emiatt újraimplementált valamit.)

----------------
Lvl86 Troll

Megint kapufa... :-)

Karbantartás, fordítási idő, tárhely, forrásban keresés ideje, portolás... van pár tényező.
A "fordító megoldja" komoly mérnöknél nem feltétlenül opció. Gondolkodni is kell sajna... :-)

A nem használt metódusokat nem vágja ki a gcc, mert fogalma sem lehet arról fordítási időben, hogy a Foo::Bar() metódust hívja-e valami egy másik modulból. Amiről a compiler ad warningot, pl. nem használt lokális változó, az más, sokan -werror kapcsolóval buildelnek, és irtják ezeket is. A warning free mozgalom egyébként már az OOo érában elindult évekkel ezelőtt, csak sosincs vége, mert az új compilerverziók új warningokat hoznak be.

lehetnek kivetelek -Wunused-function

Private, friend nelkuli methodusok -at sem szoktak hivni.
A linkeles idoben pedig a szokasos modon linkelt - nem sajat kodbol dlsym() vagy hasonlo modon megtalalt - nem hivatkozott, symbolumokrol lehet tudni, hogy nem szokas hivni.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

A gcc tudja, hogy mely függvények vannak exportálva a lib-ben.

Egyszer csináltam egy osztályt, ami magát regisztrálta egy listában a statikus konstruktorában. Induláskor kellett volna megmondania, hogy létezik.

Senki nem hívta az osztályt meg konkrétan, leginkább egy pluginre hasonlított.

Természetesen a linker kivágta az osztályt a fenébe, mert a kód úgysem használja, így a statikus inicializer sem indult el.

Ize ezek utan... nem ciki programozosrol irnod?
--
1 leszel vagy 0 élő vagy hulla!

Elvesztettem a fonalat. Nem értem, hogy mi köze a két témának egymáshoz.

Szerintem próbáld meg megerőltetni azt a két agysejted, hátha többre is képes vagy, minthogy minden hozzászólásom után ugyanazt a linket beküldjed.

Elsőre nehéz lesz, mert hozzászoktál, hogy bármiféle gondolkodás, vagy esetleg a téma elolvasása nélkül linkelj, de a tapasztalat azt mutatja, hogy menni fog. Már mások is belátták előtted, hogy spam küldözgetés helyett hozzászólni is lehet a hupon.

1. elolvasod a témát (nincs link)
2. megérted (még mindig nincs link)
3. ha kapcsolódik a témához linkelhetsz
4. ha nem kapcsolódik, saját kútfőből kell hozzászólni (ez őrült nehéz rész)

Most nagyon meg bantottal hehe :).

A koze az,hogy Te dumalsz a programozasrol mi kozbe halvany lila fingod nincs rola :).

--
1 leszel vagy 0 élő vagy hulla!

Te vagy a legokosabb, ezt mind elhisszük neked, mert még linkelni is tudsz, akár 200-szor is képes vagy belinkelni ugyanazt, teljesen független topikokban.

Be kell látnod, hogy nem mindenki áll az ész olyan magaslatán mint te, ezért jobban örülnénk, ha linkek küldözgetése helyett kifejtenéd a véleményed, hogy az adott állítás igaz-e, vagy nem és megpróbálnál a témánál maradni, OFF-topik faszságok helyett.

Köszi

Te mindig masok neveben beszelsz amugy?
--
1 leszel vagy 0 élő vagy hulla!

Vajon hány plugin for elromlani? :)

--
joco voltam szevasz

Elvileg egy sem, azok a stable API-t használják. Az API-ban is van sok hülyeség, régi dolog, de azt csak a majd egyszer eljövendő 4.0-ban fogják eltörni.

Egyszer láttam valahol, egy kimutatást, hogy a LibreOffice kódja milyen arányban áll C++, C, Java, Python, stb. kódokból.
Ha valaki tudja, hogy ez hol jelent meg, légszi linkelje be.

Érdekesen számol az ohloh, mert Java nincs is benne szerinte.

Csekkold ki a forrast es eressz ra egy cloc-t!

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"

a hozzaertoket kerdezem, hogy miert jobb az ilyen hasznalaton kivuli fuggvenyeket teljesen kivagni, minthogy egy kulon fajltba gyujteni. lehet kesobb megis kell egy-egy metodus, akkor azt nemkell megegyszer implementalni, hanem csak ebben a gyujtemenyben korbenezni. amolyan kodnyujtemeny, pl "hopp nekunk mar volt egy hasonlo cuccunk, keressuk csak elo".

(persze az eredeti helyrol valo torlest indokat ertem)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

A gitben elvileg meglesz minden. A régi dokumentáció is megmarad. Az más kérdés, hogy hogy lehet rátalálni évek múlva, erről megoszlanak a vélemények, hogy mennyire egyszerű.

Egyreszt, mert az altalanos gyakorlattal ellentetben a forraskod (jobb helyeken) nem egy nagy monolitikus egessze all ossze, mint a cement, amit ide-oda lehet lapatolni, es probalja kovetni a helye valamennyire azt, hogy ugyan hol is van jelentossege az adott fuggvenynek/metodusnak.

Masreszt jobb helyeken nem ujraimplementalnak egy torolt, "hianyzo" kodreszletet, hanem visszaallitjak a verziokezelovel.

Ezert nehez muunka a kodtisztitas, mert jol vegig kell gondolni, hogy mi az, amit hasznal az ember es mi az, amit nem.

Ennek is van tobb fokozata:
- statikus kodanalizis, amikor megnezed, hogy van-e valami fuggvenyre hivatkozas. Ezt ma mar minden ertelmesebb fordito megcsinalja automatikusan, csupan a kodot kell kiturni.
- dinamikus fuggvenyhivasok felderitese: na itt kezdodik a szopoag, mert mi van akkor, ha pl egy fuggveny ki lett tolva pubikus API-ba, de valojaban semmi nem hasznalja? Ez mar igenyel egy kis (jo, nagy) humaneroforrast. Tovabbi szivas tud lenni, ha egy adott fuggvenyt valami roppant trukkos modon pointrezve hivogatnak meg, amire raadasul a C/C++ eleg sok lehetoseget ad. Ezeket a fuggvenyeket raadasul akar ki is dobhatja a kodelemzo, hogy nem hasznalt. Na meg ugye ott vanaz API backward compatibility fogalma is, ha 3rd party fejlesztesek is vannak.
- raadasul a kodtisztitasnak szinten van egy 3. formaja, amikor csak halott kodreszleteket keresel. Itt is van lehetoseg valamilyen szintu statikus kodelemzesre (pl if (false)), de ezt a legkonnyebb atverni, foleg ha nagyon szet van darabolva a program tobb, onallo reszre (teszem azt .dll-re vagy .so-ra) es az egyikben egy kodreszlet lefutasa fugg attol, h egy masikban levo fuggveny mit ad vissza. Ilyen esetekben, ha olyan ertekrevizsgalunk, amely egyebkent sose johet, maris van egy gyakorlatilag halott kodreszletunk.

----------------
Lvl86 Troll

Meeks április óta SUSE-s, most már az nem Novell. Az Attachmate Groupban a SUSE önálló egység, a Novell meg egy másik. Bár még sok minden közös, a novelles e-mail címek is megvannak még, de a SUSE-set kell használni.

Ugy latom, valakinek nem volt turelme a tengelyfeliratozast megcsinalni Calcban. Pedig meg also index sem kellene. :]

--
Sent from my Ericsson SH888

Nehogy úgy járjanak mint egyik projektemen az agresszív kódtisztító kolléga :). Az eszköz szerint volt pár rutin amit nem hívott senki... aztán egy nappal a verzió kiadása után odaszólt az egyik legnagyobb ügyfél, hogy azért arról nem volt szó, hogy kidobják az egész API-t amit használnak :D