Performance vs structuur

[Verwijderd]

Beste mensen, ik ben nu zo'n 3 weken voor het eerst aan het programmeren. Ik heb geen cursus oid gehad, alles mezelf aangeleerd. Tot nu toe gaat het wel oke. Maar ik moet nu toch ff advies vragen.

Ik ben dus bezig met het ontwikkelen van een game voor een mobile device. Na 2 weken had ik de functionaliteit zo goed als af, maar als ik dan naar m'n code keek werd ik daar niet vrolijk van. De code was niet bloated ofzo, juist niet, alles was heel direct en to-the-point maar juist daarom werd de code moeilijk te begrijpen. Ik gebruik een object-oriented taal, maar een logische indeling in classes ontbrak in mijn programma een beetje. Ik maakte geen gebruik van Model classes maar propte alle functionaliteit in een Controller class. Het werkte, maar het was geen nette en onderhoudbare code.

Dus begon ik mijn app te herschrijven. Ik bedacht vooraf een logische class-structuur, hield Model classes zoveel mogelijk gescheiden van Controller en View classes, documenteerde alles netjes. Het resultaat was, al zeg ik het zelf, een redelijk nette structuur die denk ik wel volgens het boekje was. De code was goed te lezen/begrijpen, functionaliteit veranderen/toevoegen werd simpel, kortom: nette, overzichtelijke code. Maar bij het testen begon me steeds meer op te vallen dat de performance achteruit was gegaan. Waar m'n oude app heel snel en snappy draaide had m'n nieuwe versie een beetje last van "lag". Logisch ook, want ik had meer classes en methods toegevoegd en dat betekent overhead. De oude code was veel "directer" en vereiste veel minder method calls.

En nu ben ik dus in dubio. Aan de ene kant werk ik veel liever met de nieuwe code, die is voor mij veel prettiger te onderhouden. Maar ik vind het jammer dat ik dan aan performance moet inboeten, vooral omdat je op een mobile device toch liever een snelle en lichte app draait.

Wat zeggen jullie? Is het verstandig om sowieso een goede structuur te hebben die makkelijk te onderhouden is, zodat je later makkelijker kan optimaliseren/finetunen om alsnog meer performance te krijgen, of is het slimmer om nu de meest efficiente (snelle) codebase te pakken en daar op voort te borduren?

Houd ook in het achterhoofd dat het om een mobile app gaat; als het om een desktop app ging had ik sowieso de gestructureerde versie gehouden aangezien de performance dan veel minder een issue was, maar op een mobile device wil je toch rekening houden met performance en batterijduur.

Ik hoor graag jullie meningen.

[Stukfruit]

Je zegt het zelf al: op een "mobile device" wil je snelheid en kies je wat het beste is om dat te krijgen. Als je daarvoor niet een mooi frameworkje er omheen kan maken dan zou ik dat ook zeker niet doen. Er zijn genoeg andere manieren om je code redelijk mooi mee te maken zonder overal een "object" tegenaan te gooien (wat op de desktop trouwens ook niet altijd verstandig is).

Daarnaast geef je erg weinig informatie. Welke taal gebruik je bijvoorbeeld? Welk soort "mobile device" hebben we het hier over? En heb je er al met een profiler doorheen gelopen om te kijken waar de verschillen in zitten?

[ Voor 4% gewijzigd door Stukfruit op 30-09-2008 06:47 ]

[JKVA]

Structuur en performance hoeven elkaar niet uit te sluiten. In een taal als Java (en ik verwacht ook .NET) heeft het zelfs voordelen om code netjes op te zetten. Voor de ingebouwde JIT compiler is het namelijk veel gemakkelijker om @runtime performance tweaks te doen aan nette, OO code dan aan 'onleesbare' code.

Daarnaast is het bij nette code gemakkelijker om later zelf nog aanpassingen te doen om de performance te verbeteren.

Maar het hangt erg af van je platform...

[Orphix]

Zoals hierboven gezegd, we kunnen er niks zinnigs over zeggen zonder dat je ons meer details geeft. Maar in het algemeen kan je ervan uit gaan dat de overhead van meerdere method calls verwaarloosbaar is. Structuur en performance, zeker op macro-niveau, zijn geen uitsluitende facetten: je kan beiden hebben. Dit in tegenstelling tot snelheid en geheugen bijvoorbeeld, waarbij vaak wel een trade-off is.
In het algemeen kan je de 80/20 regel toepassen: 80% van de tijd wordt doorgebracht in 20% van de code. Daar moet je je focus op leggen, maar het is verstandig om daarvoor een profiler te gebruiken zoals hierboven ook al staat.

[BCC]

Juist bij Mobile devices wil je in eerste instantie zoveel mogelijk structuur hebben. Gezien de verscheidenheid en ontwikkelsnelheid van telefoons tegenwoordig kun je er vrij zeker van zijn dat de specifieke code voor model a niet goed werkt op model b. En aangezien je app zeker meerdere generaties telefoons mee moet, wil je dit met zo min mogelijk werk kunnen doen.

Mijn ervaring is met hierboven. Maak eerst een zo goed en zo net mogelijke struktuur. Ga dan kijken waar het klemt qua performance (dit is echt heel belangrijk, omdat vooral met mobile devices mensen heel ongeduldig zijn).

Kijk vervolgens of je het daar netjes kan oplossen of moet hacken. Helaas zijn de huidige mobile devices soms toch nog zo beperkt dat je dingen moet hacken (specifieke code schrijven), maar dat is aan de andere kant ook wel onderdeel van de charme.

Dus: profilen, profilen, profilen, profilen!

[ Voor 10% gewijzigd door BCC op 30-09-2008 12:26 ]

[Phyxion]

JKVA schreef op dinsdag 30 september 2008 @ 08:49:
Structuur en performance hoeven elkaar niet uit te sluiten. In een taal als Java (en ik verwacht ook .NET) heeft het zelfs voordelen om code netjes op te zetten. Voor de ingebouwde JIT compiler is het namelijk veel gemakkelijker om @runtime performance tweaks te doen aan nette, OO code dan aan 'onleesbare' code.

Daarnaast is het bij nette code gemakkelijker om later zelf nog aanpassingen te doen om de performance te verbeteren.

Maar het hangt erg af van je platform...

Java en performance?
Nee, in sommige gevallen is het beter om voor performance te kiezen dan structuur in je code.
Probeer veel commentaar te zetten zodat het toch nog redelijk leesbaar blijft.

[Soultaker]

Wat zeggen jullie? Is het verstandig om sowieso een goede structuur te hebben die makkelijk te onderhouden is, zodat je later makkelijker kan optimaliseren/finetunen om alsnog meer performance te krijgen, of is het slimmer om nu de meest efficiente (snelle) codebase te pakken en daar op voort te borduren?

In het begin doe ik zelf vaak geen van beide; ik heb wel een globaal idee van hoe ik iets wil modelleren, maar begin meestal met een to-the-point implementatie (dat is dan vaak niet eens de meest efficiënte) en probeer later te refactoren naar nettere code. Dat werkt vaak goed, mits je wel van te voren je doelstructuur in de gaten houdt, anders moet je je hele code base omgooien. Het is dus een kwestie van balans zoeken tussen snel genoeg resultaten boeken om te kunnen zien waar problemen zitten (en jezelf gemotiveerd te houden) enerzijds en op tijd refactoren om de boel overzichtelijk en onderhoudbaar te houden anderzijds.

Het bovenstaande verhaal heeft eigenlijk heel weinig met performance te maken; in mijn ervaring verbetert refactoren niet alleen de structuur maar vaak ook de performance (tenminste, ik probeer bottle necks die ik gevonden heb dan ook weg te werken). Misschien kun je eens benchmarken waar de performance problemen vandaan komen? Ik denk dat het in het algemeen goed mogelijk moet zijn om een nette structuur te combineren met redelijke performance, zeker aangezien mobiele devices ook weer niet zo heel traag zijn. Tot op de laatste byte optimaliseren zou dus niet nodig moeten zijn. Mag ik vragen met wat voor programmeertaal/platform je werkt?

[Haan]

Profilen dus En dan kan je daarna een topic in PRG openen om je te helpen met kijken hoe je code beter/sneller kan als je de pijnpunten hebt gevonden

[daniëlpunt]

BCC schreef op dinsdag 30 september 2008 @ 12:24:
Juist bij Mobile devices wil je in eerste instantie zoveel mogelijk structuur hebben. Gezien de verscheidenheid en ontwikkelsnelheid van telefoons tegenwoordig kun je er vrij zeker van zijn dat de specifieke code voor model a niet goed werkt op model b. En aangezien je app zeker meerdere generaties telefoons mee moet, wil je dit met zo min mogelijk werk kunnen doen.

Mijn ervaring is met hierboven. Maak eerst een zo goed en zo net mogelijke struktuur. Ga dan kijken waar het klemt qua performance (dit is echt heel belangrijk, omdat vooral met mobile devices mensen heel ongeduldig zijn).

Kijk vervolgens of je het daar netjes kan oplossen of moet hacken. Helaas zijn de huidige mobile devices soms toch nog zo beperkt dat je dingen moet hacken (specifieke code schrijven), maar dat is aan de andere kant ook wel onderdeel van de charme.

Dus: profilen, profilen, profilen, profilen!

Volgens mij is Boris bezig voor de iPhone (sorry als ik het verkeerd heb), en daar heb je (nu iig nog geen) last van de verschillende modellen. Er zijn wel verschillende modellen maar die zijn ongeveer gelijk aan hardware.

[BCC]

De iPhone 3G gaat echt niet het laatste model zijn in de serie , dus mijn verhaal verandert er niet door .

[ Voor 61% gewijzigd door BCC op 30-09-2008 12:49 ]

[JKVA]

Phyxion schreef op dinsdag 30 september 2008 @ 12:29:
[...]
Java en performance?

Java is tegenwoordig (zeker sinds Java 6) retesnel. Minstens vergelijkbaar met C++ en C#.

Nee, in sommige gevallen is het beter om voor performance te kiezen dan structuur in je code.
Probeer veel commentaar te zetten zodat het toch nog redelijk leesbaar blijft.

Afhankelijk van wat je bedoelt, is dit wel of niet waar.

Performance mag bijvoorbeeld geen enkele reden zijn om niet voor OO te kiezen. De overhead van method calls is nihil en wordt vaak zelfs helemaal geëlimineerd doordat de Java runtime code kan inlinen.

Aan de andere kant moet je wel je algoritmes op orde hebben. En niet overbodig dure operaties uitvoeren, maar uitkomsten bewaren. Dus op dat punt ben ik het wel met je eens.

[Verwijderd]

Excuses voor de weinige informatie vooraf, ik wou eerst vooral algemene en platform-onafhankelijke tips en advies. Maar goed, het betreft hier inderdaad de iPhone/iPod touch SDK, icm Objective-C 2.0. Er is dus nog vrijwel geen sprake van verschillende modellen waar ik rekening mee moet houden, het OS is praktisch hetzelfde op alle modellen. Mag ik vragen wat dat profilen precies inhoudt?

[Hielko]

Ik weet niet wat voor tools er bij de Iphone sdk zitten, maar met een profiler kan je in kaart bringen welke code het meest uitgevoerd wordt/waar de meeste cpu-cycles worden besteed. Als je de prestaties van je applicatie wil verbeteren kan je door middel van een profiler achterhalen welke stukken code je dan aan moet gaan pakken.

[.oisyn]

JKVA schreef op dinsdag 30 september 2008 @ 13:18:
Performance mag bijvoorbeeld geen enkele reden zijn om niet voor OO te kiezen. De overhead van method calls is nihil en wordt vaak zelfs helemaal geëlimineerd doordat de Java runtime code kan inlinen.

Method calls optimizen zijn micro-optimizations. Echter, wat de oorzaak is van veel methods en een puristische OO structuur is over-abstractie, en dat is weldegelijk van grote invloed op performance, omdat er vaak geen aannames meer gemaakt kunnen worden waardoor de compiler de code minder goed kan optimizen en omdat de code algoritmisch anders in elkaar gaat zitten.

Performance is idd geen reden om niet voor OO te kiezen, maar het is wel een reden om de OO idealogie niet te ver door te drammen, hoe "mooi" je code er ogenschijnlijk ook door wordt.

---

Profilen is simpelweg het nameten van je code zoals dat runt op de CPU, en wat voor bijwerkingen het heeft. Denk aan tijd gespendeerd in functies en hoeveel geheugen wordt gebruikt. Door te profilen kom je erachter waar de hotspots zitten en dus welke delen van de code het belangrijkst zijn om te optimaliseren.

Hielko schreef op dinsdag 30 september 2008 @ 14:59:
Ik weet niet wat voor tools er bij de Iphone sdk zitten, maar met een profiler kan je in kaart bringen welke code het meest uitgevoerd wordt/waar de meeste cpu-cycles worden besteed. Als je de prestaties van je applicatie wil verbeteren kan je door middel van een profiler achterhalen welke stukken code je dan aan moet gaan pakken.

Profilen hoeft natuurlijk niet per se dmv een externe profiler. Je kunt ook gewoon simpelweg functies gaan timen door de code te instrumenteren.

[ Voor 34% gewijzigd door .oisyn op 30-09-2008 15:02 ]

[daniëlpunt]

Hielko schreef op dinsdag 30 september 2008 @ 14:59:
Ik weet niet wat voor tools er bij de Iphone sdk zitten, maar met een profiler kan je in kaart bringen welke code het meest uitgevoerd wordt/waar de meeste cpu-cycles worden besteed. Als je de prestaties van je applicatie wil verbeteren kan je door middel van een profiler achterhalen welke stukken code je dan aan moet gaan pakken.

de profiler van de iPhone SDK heet Instruments.