Algemeen: cachen van method calls

[HawVer]

Ik ben op het moment bezig met een 2d vector library in c#. Dit project maakt gebruik van zijn eigen objecten, zoals een square, circle, ellipse etc. Op het moment dat ik deze objecten wil 'renderen' wordt een hele reeks methoden uitgevoerd. Welke methoden dat zijn wordt runtime bepaald en is afhankelijk van het type object. Het probleem is dat dit bepalen van methoden aanroepen nogal vaak gebeurd. Het liefst zou ik de aanroepen willen cachen.
Ik heb alleen mijn twijfels of dit echt performance winst oplevert. Maar goed ik heb al wel wat gevonden over memoizing van methode aanroepen maar memoizing cached het resultaat van een methode aanroep en niet de aanroep zelf. Hoe zou ik dit het beste kunnen aanpakken?

[whoami]

ik denk dat het adagio 'premature optimizations are the root of all evil' best wel eens van toepassing zou kunnen zijn ...

Maw: ik zou me hier nog niets van aantrekken; indien blijkt dat je library echt te traag is, kan je gaan profilen om na te gaan wat er waar traag gaat. Dan kan je direct zien waar je snelheidswinst kunt halen.

[HawVer]

whoami schreef op dinsdag 10 juni 2008 @ 10:57:
ik denk dat het adagio 'premature optimizations are the root of all evil' best wel eens van toepassing zou kunnen zijn ...

Dat zou goed kunnen omdat het complexer wordt.

Maw: ik zou me hier nog niets van aantrekken; indien blijkt dat je library echt te traag is, kan je gaan profilen om na te gaan wat er waar traag gaat. Dan kan je direct zien waar je snelheidswinst kunt halen.

Het liefst wil ik het probleem bij voorbaat al oplossen. Ik weet vrijwel zeker dat dat een trage factor zal worden. Ik maak nl gebruik van een externe library voor het tekenen, nl. Cairo. Cairo maakt gebruik van kleine methodes zoals cairo_curve_to. Als ik alleen die methoden gebruik in de onPaint is het razend snel. Het liefst wil ik dat ook bereiken dmv caching, oid

[ Voor 16% gewijzigd door HawVer op 10-06-2008 11:41 ]

[Janoz]

Het door Whoami aangehaalde adagio betekend meer dat je niet problemen moet gaan proberen op te lossen die er nog niet zijn.

Ik krijg echter het idee dat 'cachen' niet het woord is wat je zoekt. Ik kan het complete mis hebben, maar volgens mij wil jij op zoek naar een datastructuur waarmee je de tekenoperaties kunt optimaliseren.

Zou je misschien een voorbeeldje kunnen geven aan de hand van een paar squares en circles wat je nu eigenlijk zou willen bereiken?


-edit-

of is cairo puur een math lib? In dat geval denk ik dat het hele caching gebeuren je weinig gaat helpen. Elke bereking is redelijk specifiek en zeker door het slecht kunnen matchen van floats zul je eerder een memory slurpende nauwlijks beter performende applicatie krijgen.

[ Voor 23% gewijzigd door Janoz op 10-06-2008 13:04 ]

[HawVer]

Janoz schreef op dinsdag 10 juni 2008 @ 13:02:
Het door Whoami aangehaalde adagio betekend meer dat je niet problemen moet gaan proberen op te lossen die er nog niet zijn.

Daar ben ik het mee eens.

Ik krijg echter het idee dat 'cachen' niet het woord is wat je zoekt. Ik kan het complete mis hebben, maar volgens mij wil jij op zoek naar een datastructuur waarmee je de tekenoperaties kunt optimaliseren.

Het optimaliseren van mijn datastructuur zou ook een oplossing kunnen zijn.

Zou je misschien een voorbeeldje kunnen geven aan de hand van een paar squares en circles wat je nu eigenlijk zou willen bereiken?

Zeker, het is een voorbeeld in pseudocode:


Haal geometry op
Is het een square?
Haal segmenten op
Teken de square segmenten

Haal volgende geometry
Is het een ellipse?
Haal segmenten op
Teken de ellipse

Dit is natuurlijk een erg vereenvoudigd beeld omdat in de praktijk ook transformaties e.d. meedoen. De onderlijnde zaken zijn dingen die je niet steeds opnieuw wilt uitvoeren omdat de segmenten niet veranderen. De daadwerkelijk teken operaties zijn een reeks kleine methoden aanroepen met steeds dezelfde data.

Misschien zoek ik het in de verkeerde hoek, maar ik wil object 1 deze methoden met deze data aanroepen, ik wil voor object 2 deze methoden met deze data aanroepen. Ik heb in het begin al bepaald welke methoden ik moet aanroepen zodat er een Ellipse op beeld verschijnt. Volgen jullie het nog?

Wat een oplossing zou kunnen zijn is dat ik elk van de classen verantwoordelijk maak voor het tekenen van zichzelf. Maar dat wil ik liever niet omdat ik op een later tijdstip misschien ook GDI wil ondersteunen.

-edit-

of is cairo puur een math lib? In dat geval denk ik dat het hele caching gebeuren je weinig gaat helpen. Elke bereking is redelijk specifiek en zeker door het slecht kunnen matchen van floats zul je eerder een memory slurpende nauwlijks beter performende applicatie krijgen.

Cairo is vergelijkbaar met Extended GDI. Ik geef een surface en roep methoden aan die resulteren in een 2d drawing. Alleen is Cairo erg low level.

[Janoz]

Ik zie het probleem eigenlijk nog niet zo. Ten eerste weet een elipse toch wel dat het een elispe is en hoe hij eruit ziet?

[.oisyn]

Kun je je shapes niet gewoon vertalen naar een lijst van draw commando's, die je dan uitvoert als je een shape wilt tekenen? En dan kun je denken aan een id voor elke verschillen de call die je dan in een switch statement afhandelt, de OO manier waarop je een simpele CairoDrawable interface bouwt met een Draw() methode, met implementaties voor elk mogelijk commando, of zelfs letterlijk een functie/IL genereren die alle calls netjes uitvoert.

[Alarmnummer]

Er zijn bepaalde technieken waarmee je het cachen transparant kunt maken (bv via een proxy of aspecten). Maar daardoor kun je ook subtiele bugs introduceren. Bv concurrency problemen als het object dat je terug geeft mutable is en de aanroep door meerdere threads gedaan kan worden.

[YopY]

HawVer schreef op dinsdag 10 juni 2008 @ 14:25:

Zeker, het is een voorbeeld in pseudocode:


Haal geometry op
Is het een square?
Haal segmenten op
Teken de square segmenten

Haal volgende geometry
Is het een ellipse?
Haal segmenten op
Teken de ellipse

Lijkt mij niet de optimale manier om het op te lossen. In nog meer pseudocode lijkt mij dit als

code:

for (Geometry in Geometries)
{

if Geometry.Type == 'square'
{
   doeIets(); 
   doeIetsAnders();
} else if Geometry.Type == 'ellipse'
{
   rinse();
   repeat();
}
}

terwijl je liever een structuur wilt hebben als

code:

for (Geometry in Geometries)
{
   Geometry.drawOn(Canvas);
}

waar je het uiteindelijke tekenen uitbesteedt aan het object wat precies weet wat en hoe het getekend wordt.

Maar ik kan het mishebben natuurlijk, je kunt niet veel uit pseudocode halen.

[MLM]

gebruik je virual methods en/of interfaces voor je drawable objecten?

Dit is wat ik normaal zou verwachten voor iets wat verschillende objecten kan tekenen

C#:

//interface
interface Tekenbaar
{
   void Teken(Canvas naar);
}

//een vierkant
public class Vierkant : public Tekenbaar
{
   void Teken(Canvas naar)
   {
       //teken 4 lijnen
   }
}

//een collectie objecten
class Objecten
{
   List<Tekenbaar> _objecten;

   //methods om objecten toe te voegen aan de list e.d.
   
   public void TekenAlles()
   {
      foreach(Tekenbaar t in _objecten) t.Teken();
   }
}

Ik code normaal C++, dus mss zitten er wat foutjes in, maar het idee is duidelijk lijkt me

[.oisyn]

Hmm ik ging er eerlijk gezegd al vanuit dat het ontwerp wel op die manier in elkaar zou zitten

[Janoz]

Assumption is the mother of all fuckups

[HawVer]

Wat een oplossing zou kunnen zijn is dat ik elk van de classen verantwoordelijk maak voor het tekenen van zichzelf. Maar dat wil ik liever niet omdat ik op een later tijdstip misschien ook GDI wil ondersteunen.

.oisyn schreef op dinsdag 10 juni 2008 @ 15:33:
Hmm ik ging er eerlijk gezegd al vanuit dat het ontwerp wel op die manier in elkaar zou zitten

@Iedereen,
Bedankt voor de oplossingen. Ik denk dat ik het zo ga gebruiken. Ik maak een interface aan voor mijn drawing functionaliteit zodat ik later ook GDI kan toevoegen. Mijn cairo drawing class implementeert mijn drawing interface. En elke class die tekenbaar is krijgt een mooie drawable interface.

Alarmnummer schreef op dinsdag 10 juni 2008 @ 14:54:
Er zijn bepaalde technieken waarmee je het cachen transparant kunt maken (bv via een proxy of aspecten). Maar daardoor kun je ook subtiele bugs introduceren. Bv concurrency problemen als het object dat je terug geeft mutable is en de aanroep door meerdere threads gedaan kan worden.

Ehh,, dat doe ik dan maar niet..