Hali!
Először is pár észrevétel, mit lehetne javítani:
- Meg kéne csinálni úgy a vizualizálót, hogy az indexernél szögletes zárójelbe ne csak a különböző index kulcsok számát írjuk ki, hanem az indexerben jegyzett összes tuple számát is. Ez persze lehet, hogy lassú. Sőt, utóbbi fontosabb lenne - nem az az érdekes memóriafoglalás szempontjából, hogy 6.3 millió különböző kulccsal vannak indexelve a tuple-ök, hanem hogy hány tuple van összesen az indexerben, vagyis hány tuple ad ki ennyi különböző kulcsot. Emiatt az is lehet, hogy igazából nem is az az indexer kritikus, amit kinéztél...
- Ha a "Person.circles.members" navigációs kifejezések köztes állomásait elneveznénk valahogy, akkor követhetőbbek lennének az ábrák
- Azért el lehetett volna kicsit jobban rendezgetni azt a Rete ábrát, hogy ki lehessen venni, mi is van... meg kivenni a fölösleges mintákat... de persze a legjobb élőben megnézegetni, elolvasni a hovereket, stb.
Mindenesetre ezt sikerült leszűrni:
A "MutualFriends" minta így néz ki:
nem érdekes resztli rész: person!=friend, person:Person, friend:Person
érdekes rész: person |--circles---> C1 |--members---> friend |---circles--> C2 |---members--> person // négy változó, négy élkényszer, egy kör
A "brutal" hálóból ez látszik:
I. valahogy megvan a person |--circles---> C1 |--members---> friend, ez kibogozhatatlan mivel nincs igazán elrendezve a vizualizáció, de gondolom egy members és egy circles joinja (plusz a Person bejoinolva, de az nem számít sokat)
II. itt ellenőrzi le, hogy a két ember különbözik-e (mert most kerültek egy tuple-be)
III. hozzájoinol egy memberst: C2 |---members--> person |--circles---> C1 |--members---> friend
IV. hozzájoinolja a maradék circles élet is
A "normal" hálóból ez látszik:
I valahogy összejoinol minimum egy memberst és egy circlest, sajnos nem látszik, hogy a person vagy a circle mentén, de közvetetten azt gyanítom, hogy az ember mentén: C2 |---members--> person |--circles---> C1
II. hozzájoinol egy circles élet: friend |---circles--> C2 |---members--> person |--circles---> C1
III. itt ellenőrzi le, hogy a két ember különbözik-e (mert most kerültek egy tuple-be)
IV. hozzájoinolja a maradék members élet is
Okos következtetést nem tudok levonni. Valószínűleg nem a különbözőségellenőrzés számít sokat. A metamodell, sőt az egyes típusok példányszámának ismeretében sem világlik ki semmi feltűnő, ami alapján az egyiknek jobbnak kéne lennie. Gyanús, hogy nagyon modellfelépítés-specifikus, hogy ebben a két stratégiában ekkora különbség van és ebben az irányban... már ha egyáltalán itt van a jelentős különbség (sajnos csomó más minta is van, mi zajt csinál). Ugye a worst case három ilyen él joinolására 10 000 x 10 x 10 x 10 = 10 000 000 tuple, az egyik esetben ehhez közel jár, a másik irányban joinolgatva meg sokkal kevesebb is kijöhet, mert úgy van felépítve a modell.
Hogyan lehetne ezen javítani?
a. Mondjuk ha eleve értelmesebb mintát írunk, és mindkét "Person.circles.members" navigációt ugyanazon segédminta hívásával intézzük el (ezt mondtam eleve Ábelnek)
b. Tervbe van amúgy (egy hete issue-ba is fel van írva:
https://github.com/ujhelyiz/EMF-IncQuery/issues/326#issuecomment-12039650 ) egy olyan nem is nagyon nehéz optimalizáció, ami az ilyen hasonlóságokat észreveszi és proaktívan node sharing-et kezdeményez. Konkrétan az történne, hogy amikor építés közben (akármelyik esetet nézve a kettő közül) az I. lépés megvan, pl. person |--circles---> C1 |--members---> friend, akkor azonnal észrevenné, hogy ugyanez a csomópont friend |--circles---> C2 |--members---> person mintát is reprezentálja, és akkor ezt a csomópontot önmagával összejoinolva (plusz resztli) már kész is lenne a teljes minta viszonylag olcsón. Ez egy olyan node sharing trükk, amit igazából az eredeti Rete cikk is ír, csak soha nem vettem a fáradságot a leimplementálására (mert amíg főleg én írtam mintákat, addig nem volt rá szükség, mert fejben úgyis megcsináltam automatikusan :D ).
(Mintha a amúgy a Person típuskényszer kioptimalizálása nem működne valamiért, ennek egyszer utána lehetne nézni... de szvsz nem itt úszik el a dolog, nem akkora nagy költség egy Personra újra megnézni, hogy Person)
Üdv
Gaben
-----incquery-developers@xxxxxxxxxxxxxxxx ezt írta: -----Címzett: "incquery-developers@xxxxxxxxxxxxxxxx" <incquery-developers@xxxxxxxxxxxxxxxx>
Feladó: Istvan Rath
Küldte: incquery-developers@xxxxxxxxxxxxxxxx
Dátum: 2013/01/15 10:28de.
Tárgy: Re: Fura teljesítményprobléma
Sziasztok!
Újabb fejlemények:
2) Néha, ahogy a logban is látjátok, "elszabadul a pokol", és a normális 5-600MB körüli heap helyett elmegy egészen 4-5-6GB-ig a heapfoglalás, és a futási idő kb 10-20x megnő. Ez a jelenség nemcsak a mérésnél, hanem normál használat közben is jelentkezik, azaz néha gyorsan lefut az IQ inicializálás (azért GUI-n sosem tart mondjuk 10 sec-nél kevesebb ideig), néha pedig percekig beachball (és a háttérben 6GB-os heap). Vajon mi lehet ennek az oka?
Úgy néz ki, hogy Gaben megérzése jó volt azt illetően, hogy a "normál" és a "brutál" esetben (ugyanarra a mintahalmazra) más-más Rete háló épül. Lásd csatolmányok.
Mostmár csak az a kérdés, hogy ez mitől van és hogyan lehetne kiküszöbölni.
üdv
István
[a(z) "brutal.png" mellékletet Gábor Bergmann/ftsrg törölte]
[a(z) "normal.png" mellékletet Gábor Bergmann/ftsrg törölte]
[a(z) "Archive.zip" mellékletet Gábor Bergmann/ftsrg törölte]
[a(z) "Rete_brutal.png" mellékletet Gábor Bergmann/ftsrg törölte]
[a(z) "Rete_normal.png" mellékletet Gábor Bergmann/ftsrg törölte]
