[ALG]Wat maakt een applicatie snel?

[DroogKloot]

Heel simpel, een programma loopt vlot(ter) door het gebruik van:

1. Snelle datastructuren
2. Snelle (sorteer-, etc) algoritmes
.
.
.
3. Overige optimalisaties

Stukken code in assembly schrijven valt onder 3, en levert hooguit een constante factor aan snelheidswinst op. De eerste twee punten zijn verreweg het belangrijkste, een datastructuur waarin een zoekoperatie O(log n) tijd kost is bijvoorbeeld belachelijk veel sneller dan een ds. waarin zo'n operatie O(n) tijd kost wanneer er veel zoekacties in grote datasets gedaan worden. Dat soort dingen tellen veel zwaarder dan op micro-niveau op een paar instructies bezuinigen.

[.oisyn]

eghie schreef op zondag 28 oktober 2007 @ 22:20:
Het zou ook kunnen zijn dat het design van je software je forceerd om meer code te schrijven om iets te regelen, wat het dan ook trager maakt. Events met polling is trager dan de code rechtstreeks onder een actie te hangen, ook al scheelt het normalitair niet veel. Is het dan zo dat deze applicaties "slecht onderhoudbaar" zijn ontworpen, om toch zo snel te kunnen zijn?

En een over-designed n-tier OO app draait vaak ook een stuk trager dan een pragmatisch maar wellicht minder "mooi" ontworpen down to earth app (de scheiding van componenten zorgt voor slechte optimalisaties en veel indirecties). Ik heb het idee dat veel Java applicaties van die eerste categorie zijn, maar eerlijk gezegd is dat meer een onderbuik-gevoel.

[Kuhlie]

Je hebt het ook over Firefox: deze is - voor zover ik begrepen heb - relatief traag doordat gekozen is om een groot deel van de gui in javascript is geschreven. Het voordeel is dat je er alles, maar dan ook alles, in kunt veranderen (add-ons), wat je bij Opera, waar je het mee vergelijkt, niet of in veel mindere mate kunt.

Een keuze van snelheid tegenover veelzijdigheid, dus.

[roy-t]

compiler.compileforspeed = true;



(in VB6 kon dat nog iig )

[sopsop]

therat10430 schreef op maandag 29 oktober 2007 @ 07:55:
compiler.compileforspeed = true;



(in VB6 kon dat nog iig )

Lijkt me stug met die ; erachter

[RobIII]

In VB6 kon je ook nog kiezen of je wou compilen voor native code of P-code

Anyway; ik wil hier wel even een keer van de mythe af dat (hand-coded) assembly sneller zou zijn dan code van een hoge(re) taal als C++, C#, Java of whatever. In principe zou dat moeten kunnen/zijn, echter met de complexiteit van de huidige processors (en dan heb ik het over branche-prediction, pipeline optimalisations, cache levels etc. et.c) kun je als 'human' haast niet meer op tegen een compiler die een 3GL of hoger omzet naar een binary; een compiler weet (zeker als het toegesneden is op een bepaalde CPU) veel beter gebruik te maken van dit soort optimalisaties dan je zelf zou kunnen. Natuurlijk kun je uitgepoepte code nog wat proberen te optimizen maar dan moet je al verrekkes goed weten waar je mee bezig bent.

Daarnaast is het schrijven in assembly ook nog eens vele malen arbeidsintensiever en loont het zich alleen in de extreme gevallen waar optimalisatie echt cruciaal is; het is echter 99 v/d 100 keer (om het zo maar te zeggen) dan beter om er gewoon een dikkere CPU onder te duwen dan in assembly te gaan zitten klooien. Als je daar je optimalisaties al uit moet gaan halen heb je het dus meestal al ergens anders verkeerd aangepakt of te lage systeemeisen gesteld

Verder zijn er natuurlijk nog 1001 verschillende parameters die bepalen waarom de ene app snel/klein/compact is en de andere niet; er is (IMHO) geen "dé" richtlijn die daar iets over zegt behalve gewoon je gezond verstand gebruiken als devver.

[ Voor 18% gewijzigd door RobIII op 29-10-2007 11:01 ]

[YopY]

De snelheid van applicaties (of het gebrek daaraan) is volgens mij het resultaat van het gebruik maken van libraries en dergelijke. Ikzelf ben bezig met Java, waar er wel een stuk of dertig verschillende libraries gebruikt worden. Het probleem is, je weet niet hoe zwaar de functies e.d. uit die libraries zijn; voor hetzelfde gebruiken ze nog een tiental andere libraries, functie-aanroepen, etcetera.

Maar ja, daar kun je weinig aan doen, of je moet al die libraries weer zelf opnieuw maken. Ik heb het idee dat de vlottere applicaties allemaal op een lager (hoger?) niveau geprogrammeerd zijn: minder functie-aanroepen, meer gebruik van vlotte arrays ipv Lists of iets dergelijks, weinig bestandsoperaties, en wat tegenwoordig telkens meer voor een snellere applicatie zorgt met multi-core (multi-thread) processoren, is gebruik maken van threads voor herhalende (en zware) loops (moet wel zodanig zwaar zijn dat het de overhead van het aanmaken / beheren van threads goed praat).

Low-level (hoog?) programmeren is de sleutel, imo. Zodat je geen of weinig ontransparante libraries hebt en alles op het laagste niveau kunt optimaliseren.

[ Voor 7% gewijzigd door YopY op 29-10-2007 11:16 ]

[.oisyn]

YopY: dat is natuurlijk geen antwoord op de vraag, je verschuift het probleem alleen maar. "Wat maakt een applicatie snel" kun je natuurlijk ook prima interpreteren als "Wat maakt een library snel".

[roy-t]

sopsop schreef op maandag 29 oktober 2007 @ 10:43:
[...]
Lijkt me stug met die ; erachter

Doh! tsja nu haal ik programmeertalen door elkaar!

Verder kun je misschien met compileropties nog een beetje extra performance kweken, en wat me opzich ook handig lijkt is de GUI in een apparte thread zodat deze altijd netjes en meteen kan reageren. (niet dat ik zelf gebruik maak van die techniek, maar goed )

[bat266]

nja het probleem zit hem inderdaad vaak in de library's imo. Die zijn zo goed geschreven voor zo veel mogelijkheden waarvan slechts een kleine subset gebruikt wordt. Maar een lib is wel (vaak) zonder fouten je hoeft de moeite niet te doen om hetzelfde te ontwkkelen. Dus als je een goede keuze waar librarys en waar eigen code maakt dan kun je veel snelheid winnen.

[ Voor 3% gewijzigd door bat266 op 29-10-2007 11:53 ]

[Refro]

Snelle applicatie beginnen bij een design dat lean is en alleen doet wat het moet doen. Als dit vervolgens nog in een efficiente omgeving mooi geprogrammeerd wordt (met eventueel een aantal optimalisatie). Dan heb je naar mijn idee alle ingredienten voor een snelle applicatie.

Een goed bruikbare user interface valt onder een heel ander aspect de usabilaty. Maar daar heb ik geen kaas van gegeten. hoef ik voor mijn werk gelukkig ook niet te doen.

De efficientie van JIT gecompileerde talen zoals .NET en JAVA valt of staat bij de efficientie van de gebruikte JIT compiler. Door een goede JIT compiler te gebruiken die de laatste nieuwe instructies voor de intel cpu gebruikt is het in de praktijk mogelijk dat een .net managed app sneller draait als dezelfde native app.

De native app wordt namelijk voor i386 gecompileerd en kan geen gebruik maken van de latest greatest instructies in de CPU maar is wel overal compatible mee. De managed app wordt naar intermediate language gecompileerd. De rest gebeurt op de client waar een JIT compiler met de latest greatest CPU instructies draait en de applicatie dus sneller maakt als de managed code.

[matthijsln]

Deze blog post is wel interessant - gaat niet over wat een applicatie snel maakt maar juist wat het traag maakt

http://virtualdub.org/blog/pivot/entry.php?id=176#body

[RobIII]

Refro schreef op maandag 29 oktober 2007 @ 12:11:
Door een goede JIT compiler te gebruiken die de laatste nieuwe instructies voor de intel cpu gebruikt is het in de praktijk mogelijk dat een .net managed app sneller draait als dezelfde native app.

Het idee achter JIT is dat het (in principe) niet boeit op welke CPU het draait omdat het (doorgaans) in een virtual machine draait...dat je daarbij ook nog profiteert van de latest-and-greatest features als je JIT bij de tijd is is daarbij mooi meegenomen. Hoewel dat bij .Net nog niet (zo erg) zichtbaar (nog voornamelijk MS Windows (niet exclusief nee)) is zie je dat al beter bij JAVA (al behoorlijk cross-platform).

quote: http://en.wikipedia.org/wiki/Just-in-time_compilation

In a bytecode-compiled system, source code is translated to an intermediate representation known as bytecode. Bytecode is not the machine code for any particular computer, and may be portable among computer architectures. The bytecode may then interpreted, or run on a virtual machine. A just-in-time compiler can be used as a way to speed up execution of bytecode.

[ Voor 27% gewijzigd door RobIII op 29-10-2007 12:21 ]

[matthijsln]

Refro schreef op maandag 29 oktober 2007 @ 12:11:
De efficientie van JIT gecompileerde talen zoals .NET en JAVA valt of staat bij de efficientie van de gebruikte JIT compiler. Door een goede JIT compiler te gebruiken die de laatste nieuwe instructies voor de intel cpu gebruikt is het in de praktijk mogelijk dat een .net managed app sneller draait als dezelfde native app.

De native app wordt namelijk voor i386 gecompileerd en kan geen gebruik maken van de latest greatest instructies in de CPU maar is wel overal compatible mee. De managed app wordt naar intermediate language gecompileerd. De rest gebeurt op de client waar een JIT compiler met de latest greatest CPU instructies draait en de applicatie dus sneller maakt als de managed code.

Dit verhaal is theoretisch natuurlijk waar. Maar dit heeft alleen effect op "hot" code die een bepaalde taak snel moet uitvoeren en vaak wordt gebruikt. Denk aan zoeken in geheugen, optimaliseren van FPS en dergelijke. Hier spreek je trouwens over heel kleine mogelijke voordelen van een JIT.

Daartegenover staat de extra ballast van dingen die je met een managed taal gratis erbij krijgt: garbage collection, grote runtime en library, etc. Voor het "gevoel van snelheid" van de applicatie zorgen die juist voor een trage ervaring.

Bij de eerder genoemde taken heb je al minder snel het gevoel van traagheid, vooral als je een mooie voortgangsindicator maakt en je zorgt dat je interface altijd snel reageert, snel wordt hertekend als er een ander window overheen is geweest en zonder flicker, zonder secondenlang geswap, etc...

[.oisyn]

RobIII: Wat je is punt nou, anders dan het valide puntje dat het niet gelimiteerd is tot Intel CPUs? Bytecode is crossplatform ja, maar een JIT compiler niet, want die zet bytecode om naar machinecode. Het idee achter bytecode is dat het op elke machine draait. Het idee achter JIT is dat die bytecode voor een specifiek platform wordt omgezet naar machinecode .

matthijsln: de grote van de runtime library en het feit dat er een GC draait heeft weinig te maken met het gevoel dat een app traag is - dat zou betekenen dat een applicatie in C++ met een GC (het memory model van C++ sluit het gebruik van een GC niet uit!) en een grote standaard library ook per definitie traag is, wat niet zo is. Noch is een GUI app in Java of .Net per definitie traag (java AWT performt over het algemeen prima). De JIT compiler zul je wel gaan merken though - bytecode is constant onderhevig aan hercompilaties en optimalisaties naarmate het gebruik van de app steeds meer convergeert naar het totale gemiddelde.

Ik zei het al, en Refro haalde het nog een keer aan: Waar het bij dit soort apps vooral om gaat is echt het uitgebreide design van bepaalde componenten zoals de window toolkits zoals Java Swing, die vanuit een OO standpunt erg mooi zijn met views en listeners en custom draws etc, maar zorgen voor een enorm bloated systeem. Dit zie je ook in native applicaties, zoals bijv. Office 2007 en Visual Studio 2005, waar een hele scripting interface aan vast zit.

[ Voor 60% gewijzigd door .oisyn op 29-10-2007 12:43 ]

[RobIII]

.oisyn schreef op maandag 29 oktober 2007 @ 12:30:
Wat je is punt nou, RobIII, anders dan het valide puntje dat het niet gelimiteerd is tot Intel CPUs?

Dat was het punt Verder eens met je hoor

[ Voor 5% gewijzigd door RobIII op 29-10-2007 12:41 ]

[Exirion]

De trend is al jaren: PC's zijn snel zat en hebben bergen geheugen dus waarom zou je nog optimaliseren. Verder maken veel developers er een sport van om echt _alles_ zoveel mogelijk te abstraheren zonder dat ze zich realiseren hoe onoverzichtelijk code daarvan kan worden. Overgestructureerdheid en door de bomen het bos niet meer zien is net zo goed slecht software ontwikkelen als wanneer je een wat minder elegant gestructureerde code schrijft met 50% tot 75% minder source. Combineer dit met matig aan elkaar geplakte libraries/component en slecht doordachte algoritmen en je hebt een recept voor slechte performance.

Ik werk in een hoek waarin het nog altijd de uitdaging is om het maximale uit een hardware platform te persen en waar gewerkt wordt met soms maar een paar honderd kilobyte geheugen (8051 e.d.) of hooguit een 200 tot 250MHz MIPS/ARM met een paar megabyte geheugen. Vooral daar merk je hoe slecht veel open source code is; zeker als die bedoeld is voor PC-achtige platformen. Ik ben zelf nog altijd liefhebber van zoveel mogelijk zelf ontwikkelen met zo min mogelijk ballast aan ongebruikte code. Dan heb je veel zelf in de hand, kan alles op elkaar afstemmen en vaak is code daarmee zelfs simpeler dan wanneer je hapklare brokken van het net plukt en met elkaar integreert.

Dus geen fullblown databases om een lijstje met zut op te slaan, maar gewoon ouderwets met linked lists en zelfgemaakte datastructuurtjes en bewerkingen daarop. Als je dan ook nog een beetje op data-alignment en caching-karakteristieken let dan kun je nog best leuke dingen doen met een ARM op 120MHz

[Refro]

Exirion schreef op maandag 29 oktober 2007 @ 12:50:
Dus geen fullblown databases om een lijstje met zut op te slaan, maar gewoon ouderwets met linked lists en zelfgemaakte datastructuurtjes en bewerkingen daarop. Als je dan ook nog een beetje op data-alignment en caching-karakteristieken let dan kun je nog best leuke dingen doen met een ARM op 120MHz

Helemaal correct maar wat als je een fat filesystem wil gaan ondersteunen of een connectie met het internet. Dat is allemaal wel te doen (draait tenslotte op onze 16mhz 16bit c166 gebaseerde embedded systemen) maar kost wel ontzettend veel tijd. Het gebruik van een OS (of applicatie platform) kan hier heel veel tijd besparen. Wel geef je dan zelf dingen uit handen en ben je wellicht niet helemaal tevreden met de geleverde implementatie. Maar dan doe jet het zelf toch over

[Johnny]

Opera voelt ook sneller aan omdat muisklikken worden uitgevoerd zodra een knop wordt ingedrukt, in plaats van wanneer hij wordt losgelaten zoals in andere applicaties.

[.oisyn]

Sorry maar daar klopt niets van . Ten eerste is het niet waar dat Opera al reageert op mouse-down (klik maar eens op een link zonder de muisknop los te laten), ten tweede is dat niet wat voor het gevoel van traagheid zorgt. Het voelt traag aan omdat bijv. de app lang moet opstarten, de windows langzaam painten / pagina's langzaam opbouwen, scrollen niet vloeiend verloopt, etc.

[Verwijderd]

.oisyn schreef op maandag 29 oktober 2007 @ 13:10:
Sorry maar daar klopt niets van . Ten eerste is het niet waar dat Opera al reageert op mouse-down (klik maar eens op een link zonder de muisknop los te laten), ten tweede is dat niet wat voor het gevoel van traagheid zorgt. Het voelt traag aan omdat bijv. de app lang moet opstarten, de windows langzaam painten / pagina's langzaam opbouwen, scrollen niet vloeiend verloopt, etc.

Precies. 'snelle' applicaties zijn vaak helemaal niet zo snel, ze zijn alleen zo opgezet dat ze een heel goede feedback geven aan de gebruiker. Dus geen trage paints en halfgetekende vensters en gewoon altijd reageren op je user interface (wat goed te doen is door trage acties zoals name lookups asynchroon of in een losse thread te doen).

[matthijsln]

.oisyn schreef op maandag 29 oktober 2007 @ 12:30:
matthijsln: de grote van de runtime library en het feit dat er een GC draait heeft weinig te maken met het gevoel dat een app traag is - dat zou betekenen dat een applicatie in C++ met een GC (het memory model van C++ sluit het gebruik van een GC niet uit!) en een grote standaard library ook per definitie traag is, wat niet zo is. Noch is een GUI app in Java of .Net per definitie traag (java AWT performt over het algemeen prima). De JIT compiler zul je wel gaan merken though - bytecode is constant onderhevig aan hercompilaties en optimalisaties naarmate het gebruik van de app steeds meer convergeert naar het totale gemiddelde.

Een GC levert inderdaad niet per definitie een trage applicatie op nee. Ik zal het dan nog voorzichtiger omschrijven: In de praktijk valt, met een huidige, moderne GC implementatie zoals bijvoorbeeld de Sun JRE, in bepaalde gevallen een - voor de perceptie van de eindgebruiker, daar gaat het hier immers om - duidelijk merkbare vertraging op te merken als gevolg van GC icm met een al dan niet bloated library. Dat het niet in alle gevallen "per definitie" zo is betekent niet dat het effect niet bestaat...

Lees bijvoorbeeld het blog wat ik postte, wat misschien wel meer mensen hebben gemerkt: klik je op het tray icon voor het ATI control center en doordat er een volledige GC wordt uitgevoerd moet minutenlang al het gecommitte geheugen ingeswapt worden...

[momania]

.oisyn schreef op zondag 28 oktober 2007 @ 22:57:
Ik heb het idee dat veel Java applicaties van die eerste categorie zijn, maar eerlijk gezegd is dat meer een onderbuik-gevoel.

Klopt als een bus helaas

Er wordt vaak een over-designed spul neergezet waarvan je van de ene laag naar de andere springt met de nodige abstracties erin, wat er dan qua architectuur leuk uitzien, maar vaak zo overbodig is en dus ook veel overbodige code/calls met zich mee brengt waardoor het geheel er niet echt sneller op wordt.

Nu Agile developement steeds meer door begint te dringen in de wereld van java developement zie je hier gelukkig al meer verbeteringen in. Meer KISS, etc.

[.oisyn]

matthijsnl: Wat nog altijd niets te maken heeft met waar we het hier over hebben. Wat jij beschrijft is het gevolg van memory consumption wat weer leidt tot swaps als je niet genoeg geheugen hebt, en idd heeft een garbage collected app de neiging om veel geheugen te gebruiken. Echter, terwijl je in je app werkt zullen deze swaps niet voorkomen - en toch voelen dingen traag aan.

Als ik 's morgens aan het werk ga hier dan duurt het ook even voordat m'n visual studio op gang is gekomen (ik laat m'n PC altijd aan staan), omdat er een nighly code en content build heeft gerund, waarbij de content build de neiging heeft om 1.5GB aan geheugen te verbruiken tijdens de peak. Daarna loopt het echter een stuk sneller, maar nog steeds voelt het traag aan (zeker vergeleken met VS 2003). Heeft niets te maken met de GC.

momania: Goed om te horen (Misschien is er dan toch nog een toekomst voor Java )

[ Voor 12% gewijzigd door .oisyn op 29-10-2007 13:44 ]

[momania]

.oisyn schreef op maandag 29 oktober 2007 @ 13:39:
momania: Goed om te horen (Misschien is er dan toch nog een toekomst voor Java )

Die is er zeker wel, zolang iedereen maar met gezond verstand z'n programma's schrijft. Clean, simpel, overzichtelijk en niet meer dan nodig. Java is gewoon, zeker op gebied van backend services etc. rete snel.

[Marcj]

momania schreef op maandag 29 oktober 2007 @ 13:32:
[...]

Klopt als een bus helaas

Er wordt vaak een over-designed spul neergezet waarvan je van de ene laag naar de andere springt met de nodige abstracties erin, wat er dan qua architectuur leuk uitzien, maar vaak zo overbodig is en dus ook veel overbodige code/calls met zich mee brengt waardoor het geheel er niet echt sneller op wordt.

Nu Agile developement steeds meer door begint te dringen in de wereld van java developement zie je hier gelukkig al meer verbeteringen in. Meer KISS, etc.

Helaas lijkt dit niet alleen binnen Java te gebeuren, maar ook in andere OO-talen. Ik heb laatst een project onder ogen gehad in C++ waar ook veel te veel abstracties in aangebracht zijn. Het probleem was daar ook de snelheid: ruim 500x langzamer dan de Java versie die ik nu aan het bouwen ben. Het programma was gewoon 99% van de tijd bezig met berichtjes zenden tussen de verschillende lagen...

[Exirion]

Refro schreef op maandag 29 oktober 2007 @ 12:57:
Helemaal correct maar wat als je een fat filesystem wil gaan ondersteunen of een connectie met het internet. Dat is allemaal wel te doen (draait tenslotte op onze 16mhz 16bit c166 gebaseerde embedded systemen) maar kost wel ontzettend veel tijd.

Dat doen we al Op een dergelijk systeem draait "gewoon" Linux. Met "gewoon" bedoel ik dat veel drivers voor onderdelen van het platform wel lokaal ontwikkeld worden. Oftewel een spec op je bureau en coden maar.

Maar de Linux kernel en bijvoorbeeld busybox zijn op een lichte ARM efficient genoeg om een goed bruikbaar systeem te maken. Ik doel dan ook met name op het applicatielaag gebeuren waar je met efficient programmeren leuk kunt scoren.

[mOrPhie]

Trouwens: het is leuk om 'ns naar vorige PRG-contests te kijken. Daar is in allerlei talen iets geschreven, met verschillende resultaten. In de 2e contest is het een Java-applicatie die wint. Ondanks dat de algemene tendens is dat java traag is (vanwege Bytecode -> JIT -> VM -> ABI), blijkt toch dat het niet zomaar de taal of systeem hoeft te zijn die de maakt dat een applicatie snel of langzaam is. Het is veel vaker de tijd die de devver erin steekt om dingen te optimaliseren en waar die focus ligt.

Over focus gesproken: ik zie hier veel mensen praten over een snelle GUI. Een snelle GUI geeft natuurlijk de ervaring van een snelle applicatie, maar dat hoeft niet altijd de enige doorslag te zijn. De GUI van google earth kan nog zo snel zijn (en dat istie), als het ophalen van kaart-updates lang duurt, komt dat de snelheid van de applicatie niet ten goede. De GUI is wellicht lekker responsive, maar ondertussen wacht je wel op de nieuwe kaart.

[matthijsln]

.oisyn schreef op maandag 29 oktober 2007 @ 13:39:
matthijsnl: Wat nog altijd niets te maken heeft met waar we het hier over hebben. Wat jij beschrijft is het gevolg van memory consumption wat weer leidt tot swaps als je niet genoeg geheugen hebt, en idd heeft een garbage collected app de neiging om veel geheugen te gebruiken. Echter, terwijl je in je app werkt zullen deze swaps niet voorkomen - en toch voelen dingen traag aan.

Ik stel dat een GC er in bepaalde gevallen voor kan zorgen dat een applicatie voor een gebruiker traag aanvoelt. Daarbij geef ik een voorbeeld. En volgens jou heeft dit voorbeeld niets te maken met het traag aanvoelen van een applicatie voor een gebruiker (wat is waar we het over hebben)

Als ik 's morgens aan het werk ga hier dan duurt het ook even voordat m'n visual studio op gang is gekomen (ik laat m'n PC altijd aan staan), omdat er een nighly code en content build heeft gerund, waarbij de content build de neiging heeft om 1.5GB aan geheugen te verbruiken tijdens de peak. Daarna loopt het echter een stuk sneller, maar nog steeds voelt het traag aan (zeker vergeleken met VS 2003). Heeft niets te maken met de GC.

Mooi verhaal, maar het ging niet om inswappen en traag aanvoelen van applicaties zonder GC.

[.oisyn]

matthijsln schreef op maandag 29 oktober 2007 @ 14:22:
[...]

Ik stel dat een GC er in bepaalde gevallen voor kan zorgen dat een applicatie voor een gebruiker traag aanvoelt.

En ik zeg daarbij dat die "bepaalde gevallen" waar jij het over hebt gelimiteerd is aan de situatie waarbij meerdere apps meer geheugen vreten dan in totaal in het systeem zit, en je alleen last hebt van die traagheid bij task switching. Vervolgens zeg ik dat dat specifieke geval niet is waar het in dit topic om gaat. Wat is daar nou zo moeilijk aan te snappen? Wat wil je nou horen, dat een GC soms een app eventjes traag maakt tijdens het inswappen? Fine. Kunnen we dan nu weer verder, ipv dit ene specifieke geval uit te dunnen?

[ Voor 20% gewijzigd door .oisyn op 29-10-2007 14:39 ]

[labee]

Voor preformance in C# zie de volgende filmpje van Rico Mariani.

http://creators.xna.com/H...-and-the-Unavoidable.aspx

[matthijsln]

.oisyn schreef op maandag 29 oktober 2007 @ 14:32:
En ik zeg daarbij dat die "bepaalde gevallen" waar jij het over hebt gelimiteerd is aan de situatie waarbij meerdere apps meer geheugen vreten dan in totaal in het systeem zit, en je alleen last hebt van die traagheid bij task switching.

Dat heb je dan fout. Een merkbare GC pause kan net zogoed optreden tijdens het werken met een ingeswapt programma en voldoende geheugen.

Vervolgens zeg ik dat dat specifieke geval niet is waar het in dit topic om gaat. Wat is daar nou zo moeilijk aan te snappen? Wat wil je nou horen, dat een GC soms een app eventjes traag maakt tijdens het inswappen? Fine. Kunnen we dan nu weer verder, ipv dit ene specifieke geval uit te dunnen?

Nee, dat wil ik niet horen want dat is niet zo. Als je zegt dat iets niet per definitie zo is terwijl ik dat niet stel, en wat ik zeg niets met het onderwerp te maken heeft geef ik daar wel antwoord op ja.

[farlane]

Marcj schreef op maandag 29 oktober 2007 @ 13:48:Het probleem was daar ook de snelheid: ruim 500x langzamer dan de Java versie die ik nu aan het bouwen ben. Het programma was gewoon 99% van de tijd bezig met berichtjes zenden tussen de verschillende lagen...

Dat bewijst dat de ontwerper van het C++ programma bagger werk heeft geleverd. Om in C++ een programma te schrijven dat 500x langzamer is dan een vergelijkbaar Java programma moet je toch wel erg veel lagen bouwen. ( met in elke laag een sleep volgens mij )

[Xyzar_]

een factor 500 lijkt me inderdaad ook wel wat overdreven. Zal wel brakke code geweest zijn

Ben er zelf ook recentelijk tegenaangelopen. Ben emt een project bezig met daarin 2 microcontrollers, welke middels 4 I/O pinnen verbonden zijn. Ik heb een protocol bedacht en geïmplementeerd om de twee te laten communiceren. Als ik in de java code een pin aan en uit zet (letterlijk 2 statements na elkaar, set en clear. komen uit de meegeleverde library) resulteerd dat in een puls van zo'n 20ms - 40ms. Als ik hetzelfde doe in ASM, dan worden het ineens enkele tientallen microseconden. Grofweg een factor 100, bij de implementatie van het protocol in de 2 talen was het verschil minder groot: 250ms per bericht in Java, rond de 40ms in ASM.
Kon het aan de hand van het gegenereerde beeld op de oscilloscope en doorlopen van de code ook precies terugtraceren. de vertragingen zaten hem in de delen waar java het eind van een loop bereikt en een waarde moet controleren ofzo (eind van de loop: pin wordt 0, begin van de loop: pin wordt 1, maar dan wel enkele tientallen milliseconden vertraging daartussen.)

overigens gaat het hier om een implementatie waarbij het verzenden per byte in ASM gaat, iedere afzonderlijke byte wordt dus wel door Java naar de library gegooit. Op de scope zie ik dan ook nog steeds vertraging tussen iedere byte
Gok dat ik het, als ik echt alles in ASM zou bouwen, de totale tijd per bericht wel terug zou kunnen brengen tot 10 - 20ms. (tegenover de 200 - 250ms bij de oorspronkelijke implementatie 10 tot 25x sneller)

[farlane]

Was dat een embedded Java processor?

Lijkt me trouwens wel grappig om datzelfde in C te bouwen en te kijken hoe je dan uitkomt

[ Voor 57% gewijzigd door farlane op 29-10-2007 17:00 ]

[.oisyn]

Dat vind ik niet zo heel vreemd, interop calls zijn typisch vrij duur. Je zou eens kunnen kijken of je het meer asynchroon kunt implementeren, zodat je de juiste commando's door kunt geven zonder uit de VM te hoeven treden. Je zou de commando's bijvoorbeeld naar een buffer kunnen schrijven die je IO module direct kan accessen, zodat die laatste op die commando's kan luisteren en actie kan ondernemen.

[.oisyn]

matthijsln schreef op maandag 29 oktober 2007 @ 14:50:
[...]

Dat heb je dan fout. Een merkbare GC pause kan net zogoed optreden tijdens het werken met een ingeswapt programma en voldoende geheugen.

Kijk, nu komen we ergens. Ik concentreerde me vooral op die blog entry aangezien je die zelf ook aanhield. Ik moet zeggen dat ik niet genoeg ervaring heb met GCed apps dat dit me ooit is opgevallen. Is dit echt zo merkbaar dan? En hoe vaak?

[Xyzar_]

@farlane: Als dat zo zou zijn zou ik dat wel weten zeker? nee, gok van niet.
:edit: Nee dus. Op de chip draait het TINI operating systeempje. Een eenvoudig systeem met TCP/IP functionaliteiten en een Java runtime omgeving (en want andere dingetjes, hadrware interfaces enzo)

@.oisyn: Het aantal methodeaanroepen naar de library is al redelijk beperkt nu (32x in plaats van 128 - 196. en ik kan het terugbrenegn naar 1 door gewoon de outputbuffer (char array) door te passen en de ASM code zelf door de buffer heen te laten lopen. Verder lijkt het me een beetje overkill om een apart proces te hebben draaien voor de communicatie. Het is dan wel een vrij belangrijk deel van het ding (het is overigens zo'n kaartlezer waarmee je met je pasje een deur open kan maken, voor toegangscontrole.), maar dat het programma even enkele tientallen milliseconden moet wachten is niet erg.
En daarbij, weet niet hoe belastend dit is voor de chip, maar zo snel istie nou ook weer niet (14mhz geloof ik) en de Java applicatie heeft alle processortijd en geheugenruimte zelf nodig. Kan het aardig optimaliseren om het allemaal zo beperkt mogelijk te houden, maar het blijft java...

in principe is het zo ook snel zat, hangt er vanaf hoe de rest van de software zich ontwikkeld of ik eht nog ga aanpassen. Als het in de praktijk een stuk langzamer gaat en je moet lang (seconden) wachten tot de deer opengaat nadet je je pas aanbied dan kan ik het nog herschrijven. (de array direct naarv de library passen en *alles* in ASM doen zal nog een factor 5 sneller zijn gok, als ik me de beelden van de scope goed herinner)

[ Voor 24% gewijzigd door Xyzar_ op 29-10-2007 17:44 ]

[Jeanpaul145]

RobIII schreef op maandag 29 oktober 2007 @ 10:52:
In VB6 kon je ook nog kiezen of je wou compilen voor native code of P-code

Anyway; ik wil hier wel even een keer van de mythe af dat (hand-coded) assembly sneller zou zijn dan code van een hoge(re) taal als C++, C#, Java of whatever. In principe zou dat moeten kunnen/zijn, echter met de complexiteit van de huidige processors (en dan heb ik het over branche-prediction, pipeline optimalisations, cache levels etc. et.c) kun je als 'human' haast niet meer op tegen een compiler die een 3GL of hoger omzet naar een binary; een compiler weet (zeker als het toegesneden is op een bepaalde CPU) veel beter gebruik te maken van dit soort optimalisaties dan je zelf zou kunnen. Natuurlijk kun je uitgepoepte code nog wat proberen te optimizen maar dan moet je al verrekkes goed weten waar je mee bezig bent.

Daarnaast is het schrijven in assembly ook nog eens vele malen arbeidsintensiever en loont het zich alleen in de extreme gevallen waar optimalisatie echt cruciaal is; het is echter 99 v/d 100 keer (om het zo maar te zeggen) dan beter om er gewoon een dikkere CPU onder te duwen dan in assembly te gaan zitten klooien. Als je daar je optimalisaties al uit moet gaan halen heb je het dus meestal al ergens anders verkeerd aangepakt of te lage systeemeisen gesteld

Verder zijn er natuurlijk nog 1001 verschillende parameters die bepalen waarom de ene app snel/klein/compact is en de andere niet; er is (IMHO) geen "dé" richtlijn die daar iets over zegt behalve gewoon je gezond verstand gebruiken als devver.

Gelijk geef ik je:
Ik denk dat er vanuit een developer's perspective alleen nog reden is om met assembly te werken als je aan compilerdevelopment doet.
Zo is bijv. met Linux kernel 2.6.23 een deel van de code in assembly omgeschreven naar C, omdat dit makkelijker te onderhouden is, en het snelheidsverlies minimaal.

leuk_he schreef op zondag 28 oktober 2007 @ 22:52:

Opera en utorrent zijn voorbeelden van programma's die waarschijnlijk vooral native windows libraries gebruiken en geoptimaliseerd zijn vanaf het begin.

Zegt "Premature optimalisation is the root of all evil" je iets?

[ Voor 12% gewijzigd door Jeanpaul145 op 29-10-2007 17:49 ]

[Glimi]

Jeanpaul145 schreef op maandag 29 oktober 2007 @ 17:43:
Zegt "Premature optimalisation is the root of all evil" je iets?

In mijn mening is dat geen universele regel, maar alleen een guideline om je aan het begin van het process niet te laten verleiden om micro-optimalisaties te doen. Maar als jij een sequentiele een lijst afloopt, waar je af en toe elementen uit moet verwijderen dan kies ik voor een LinkedList implementatie en niet voor een ArrayList, ook al kunnen ze hetzelfde.

[leuk_he]

Jeanpaul145 schreef op maandag 29 oktober 2007 @ 17:43:
Zegt "Premature optimalisation is the root of all evil" je iets?

Dat betekent 3 dingen:
-Dat je geen spellingscontrole in je browser hebt.
-Dat het Engels is, je had Nederlands kunnen gebruiken..


En bovenal de quote is langer...

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." and I agree with this. Its usually not worth spending a lot of time micro-optimizing code before its obvious where the performance bottlenecks are.

Je moet je MEESTALin het begin niet te druk maken over kleine optimalisaties.

[matthijsln]

.oisyn schreef op maandag 29 oktober 2007 @ 17:10:
[...]
Kijk, nu komen we ergens. Ik concentreerde me vooral op die blog entry aangezien je die zelf ook aanhield. Ik moet zeggen dat ik niet genoeg ervaring heb met GCed apps dat dit me ooit is opgevallen. Is dit echt zo merkbaar dan? En hoe vaak?

we hadden dus een misverstand door het voorbeeld uit het blog, no worries

Ik merk het wel eens bij NetBeans, een Java IDE die ik gebruik. Je kan daar in de toolbar een metertje zetten met het geheugengebruik. Wanneer je een pause opmerkt zie je daarna in het metertje dat het geheugengebruik is afgenomen door een GC*. In de huidige versie van NetBeans vallen deze pauzes trouwens erg mee. Dit hebben ze wel verbeterd sinds vorige versies, want die voelden een stuk trager aan!

Ik heb opzich dus ook niks tegen GC programma's, maar je moet toch goed rekening houden met wat de GC doet. Voor complexere applicaties moet je de GC redelijk goed tunen door parameters in te stellen of kijken of de concurrent GC een betere keuze is, etc.

Alhoewel in NetBeans een Java-editor zit met code completion, maak ik toch nog regelmatig gebruik van TextPad. Niet alleen heeft die een wat betere editor, maar voelt een stuk sneller aan Maar dat komt denk meer door het op de achtergrond compileren en code completion dan GC.

* helaas neemt de VM size niet af, deze meter geeft alleen het "interne geheugengebruik" van de JVM aan. Je ziet bijna nooit dat Java applicatie een kleinere VM size heeft dan even daarvoor (dus het echt bij het OS gealloceerde geheugen neemt niet af).

[.oisyn]

Jeanpaul145 schreef op maandag 29 oktober 2007 @ 17:43:
Ik denk dat er vanuit een developer's perspective alleen nog reden is om met assembly te werken als je aan compilerdevelopment doet.

Er wordt nog zat in assembly gedaan hoor. In de gamedevelopment bijv, maar denk ook aan grafische filters e.d., die hand-optimized SSE code bevatten. Goed, veel is het niet, het draait meestal alleen om de kleine inner loops die gigantische veel worden aangeroepen, maar het wordt weldegelijk nog altijd toegepast.

Zegt "Premature optimalisation is the root of all evil" je iets?

Ja, in die zin dat ik het er niet mee eens ben in de hoedanigheid dat jij 'm hier quote. Ga jij achteraf maar eens fijn 100 abstractielagen weg zitten werken om de applicatie beter te laten performen - dan kun je 'm net zo goed meteen helemaal herschrijven

[EfBe]

Spuit 11 1/3e zal ook even zn mening geven

eghie schreef op zondag 28 oktober 2007 @ 22:20:
Mijn vraag is dan, op welke manier moet je programmeren om je applicaties ook zo snel te krijgen? Maken ze handig gebruik van threads? Is die GUI library zo goed geoptimaliseerd en zijn de andere GUI libraries zo bloated? Is de meeste software gewoon zo resource vretend geschreven? Maken ze misschien gebruik van een soort van caching? Zijn ze misschien in assembler geschreven, om zo weinig mogelijk resources te gebruiken?

Essentieel is dat je je logica zo opzet dat je algoritmes de meest efficiente zijn die er zijn. Je kunt nog zo snel willen, maar als je algoritmes retetraag zijn, gaat je dat niet lukken.

Dat is de basis. Als je algoritmes niet goed zijn, moet je terug naar die basis, al het andere is bijzaak en lulkoek totdat je dit op orde hebt.

Van daaruit ga je aan implementatiedetails werken. Deze stap is dus pas de 1e stap (!) waarbij naar code gekeken wordt. In feite is de code een projectie resultaat van je algoritmen in executeerbare vorm. Het is dan zaak die projectie (de omzetting van wat het algoritme beschrijft in executeerbare vorm dmv code in de taal /talen naar keuze) zo efficient te laten zijn als mogelijk binnen de grenzen die gesteld zijn. Let wel: performance optimalizatie op implementatie niveau is een glijdende schaal: er is nooit een eind aan de stroom van consessies die je kunt doen voor een paar procent extra performance. Het is dan ook zaak de grenzen te stellen alvorens code te gaan optimaliseren. Dit houdt bv in dat wanneer je constateert dat een gekozen taal gewoon trager blijkt dan verwacht (bv ruby) je TOCH die code gaat houden en de performance voor lief neemt omdat de voordelen op andere gebieden de grenzen stellen dat je daar niet aan beknibbeld. Ander voorbeeld: als je gesteld hebt dat er geen inline assembler geschreven mag worden ivm onderhoudbaarheid, moet je dus genoegen nemen met een potentieel tragere implementatie. Stel je die grens niet, dan kun je voor de keuze komen te staan dat je delen in inline-assembler moet schrijven om de implementatie sneller te krijgen, en omdat die grens niet is gesteld, is dit dus een reeele optie.

Echter, wanneer moet je dan dat doen? Ten eerste moet je gewoon normaal je code schrijven. Tuurlijk zijn sommige implementaties sneller dan anderen, maar vergeet niet: aangezien je je algoritmes op orde hebt (dat is immers stap 1) is de performancewinst door een iets andere loop hier of daar niet zo bar groot. Belangrijk: een algoritme schrijft voor hoe je door datastructuren loopt bv, dus code anders opschrijven kan het algoritme veranderen, en dat is dus al niet meer aan de orde, je hebt je algoritmes uitgezocht, op Orde getest en je bent ervan overtuigd dat ze de snelste zijn.

Nadat je je code hebt geschreven ga je meten. Je gaat niet zoals prutsers die wat roepen maar niet snappen wat performance inhoudt naar code kijken en hier en daar met de natte vinger wat optimizen. Meten heet in dit geval 'profilen'.

Je code haal je dus door een profiler. Iedere taal / platform heeft wel een profiler, of de taal + platform moet sowieso niet de snelste zijn en dan is een profiler een beetje overbodig gereedschap. De profiler zal aangeven welke code verreweg de meeste keren wordt aangeroepen, en welke code al die bakken met memory alloceert bv.

Met DIE gegevens ga je terug naar de code. Omdat je weet welke routines relatief veel bijdragen aan de totale executie-tijd, ga je DIE routines op implementatie-truuks testen, je gaat kijken of je de implementatie kunt veranderen ZONDER het algoritme te veranderen. Daarna ga je weer meten, net zolang totdat je er niets meer afkrijgt.

Met deze stappen krijg je erg veel performance bottlenecks eruit. Er blijven nog een aantal over: disk I/O en memory gebruik.

Disk I/O is verreweg het traagst van alle acties in een systeem. Van de disk i/o is weer het head-stepping verreweg het traagst van allemaal. Het steppen van de disk head van track naar track wordt op een gedefragmenteerde disk veroorzaakt door meervoudige threads die allemaal de disk willen gebruiken. Dit zorgt voor onnodige stepping van de harddisk head(s) die relatief retetraag is vergeleken bij de uiteindelijke leesactie (die je toch moet doen). In VS.NET zie je bv dat men totaal niet nagedacht heeft over head-stepping. Ipv dat ze een centrale I/O queue hadden gemaakt met prioriteiten, is het elke thread voor zich. Dit levert veel disk i/o op wat veel langer duurt dan nodig.

Memory allocation is een andere traagheidsfactor. In veel gevallen is memory snel te alloceren, maar vooral bij VM gebruikende platforms is het trager dan je zou verwachten. Een profiler zal aangeven waar veel memory wordt gealloceerd, en waar je bv eventueel data kunt cachen of buffers kunt cachen.

[eghie]

leuk_he schreef op zondag 28 oktober 2007 @ 22:52:
...

Design van software is een discussie appart, maar goed /slecht design hangt niet af gebruik van welke tools, maar van je design...

...

Hiermee bedoelde ik dus, wat .oisyn hier ook zegt:

.oisyn schreef op zondag 28 oktober 2007 @ 22:57:
[...]

En een over-designed n-tier OO app draait vaak ook een stuk trager dan een pragmatisch maar wellicht minder "mooi" ontworpen down to earth app (de scheiding van componenten zorgt voor slechte optimalisaties en veel indirecties). Ik heb het idee dat veel Java applicaties van die eerste categorie zijn, maar eerlijk gezegd is dat meer een onderbuik-gevoel.

RobIII schreef op maandag 29 oktober 2007 @ 10:52:
In VB6 kon je ook nog kiezen of je wou compilen voor native code of P-code

Anyway; ik wil hier wel even een keer van de mythe af dat (hand-coded) assembly sneller zou zijn dan code van een hoge(re) taal als C++, C#, Java of whatever. In principe zou dat moeten kunnen/zijn, echter met de complexiteit van de huidige processors (en dan heb ik het over branche-prediction, pipeline optimalisations, cache levels etc. et.c) kun je als 'human' haast niet meer op tegen een compiler die een 3GL of hoger omzet naar een binary; een compiler weet (zeker als het toegesneden is op een bepaalde CPU) veel beter gebruik te maken van dit soort optimalisaties dan je zelf zou kunnen. Natuurlijk kun je uitgepoepte code nog wat proberen te optimizen maar dan moet je al verrekkes goed weten waar je mee bezig bent.

Daarnaast is het schrijven in assembly ook nog eens vele malen arbeidsintensiever en loont het zich alleen in de extreme gevallen waar optimalisatie echt cruciaal is; het is echter 99 v/d 100 keer (om het zo maar te zeggen) dan beter om er gewoon een dikkere CPU onder te duwen dan in assembly te gaan zitten klooien. Als je daar je optimalisaties al uit moet gaan halen heb je het dus meestal al ergens anders verkeerd aangepakt of te lage systeemeisen gesteld

Klopt. Over het algemeen is de boel omzetten naar assembler niet rendabel genoeg en kun je beter naar andere optimalisaties kijken. Maar ik zie hier ook een aantal reacties nu, waarbij ze op een embedded platform werken, waarbij dat wel veel scheelt. Vanwege waarschijnlijk de abstractie die er in de taal zit (JAVA bijvoorbeed).

Verder zijn er natuurlijk nog 1001 verschillende parameters die bepalen waarom de ene app snel/klein/compact is en de andere niet; er is (IMHO) geen "dé" richtlijn die daar iets over zegt behalve gewoon je gezond verstand gebruiken als devver.

Uiteraard zijn er zat verschillende mogelijkheden die bepalen hoe een bepaalde applicatie is, maar richtlijnen opzich zelf zijn er wel lijkt me. Je kunt wel met bepaalde dingen rekening houden, bijvoorbeeld references/pointers gebruiken ipv elke variable kopieeren naar een nieuwe variable als je ermee gaat werken en dan weer terug kopieeren. Dat scheelt wel in de resources. Zoals hier ook wel wordt genoemd om goed gebruik te maken van datastructures en geoptimaliseerde algoritmen, valt ook onder een soort van guideline. Uiteraard valt dat ook onder gezond verstand zoals je al zei, maar is toch iets wat veel mensen vergeten of niet eens realiseren dat het veel uit kan maken.

Exirion schreef op maandag 29 oktober 2007 @ 12:50:
De trend is al jaren: PC's zijn snel zat en hebben bergen geheugen dus waarom zou je nog optimaliseren. Verder maken veel developers er een sport van om echt _alles_ zoveel mogelijk te abstraheren zonder dat ze zich realiseren hoe onoverzichtelijk code daarvan kan worden. Overgestructureerdheid en door de bomen het bos niet meer zien is net zo goed slecht software ontwikkelen als wanneer je een wat minder elegant gestructureerde code schrijft met 50% tot 75% minder source. Combineer dit met matig aan elkaar geplakte libraries/component en slecht doordachte algoritmen en je hebt een recept voor slechte performance.

Overgestructuureerdheid zie ik inderdaad vaker voorkomen. Ik heb mezelf er ook wel schuldig aan gemaakt moet ik toegeven. Ik moet wel zeggen dat ik het soms wel moeilijk vind om hier de balans in te vinden.

Een tijdje terug zat ik wat over WAN optimizers te lezen en over de prestaties van verschillende protocollen over het WAN. Nu is een roundtrip op het WAN erg duur, vanwege de latency. Nu is er met beveiliging enzo vaak wel goed rekening gehouden met de meeste protocollen, waardoor er veel checks in zitten, maar omdat een roundtrip op WAN erg duur is, is het protocol in een WAN omgeving erg traag. Dit heeft gewoon te maken met het ontwerp van het protocol.

EfBe schreef op maandag 29 oktober 2007 @ 19:21:
Memory allocation is een andere traagheidsfactor. In veel gevallen is memory snel te alloceren, maar vooral bij VM gebruikende platforms is het trager dan je zou verwachten. Een profiler zal aangeven waar veel memory wordt gealloceerd, en waar je bv eventueel data kunt cachen of buffers kunt cachen.

Om dit op te lossen alloceren sommige applicaties aan het begin al hun geheugen waardoor ze dat niet meer hoeven te doen. Scheelt wel weer in alloceren, alleen geef je meteen wel erg veel geheugen weg aan je app en zit je eigenlijk aan een limiet voor geheugen. Uiteraard kun je alsnog meer alloceren wanneer nodig. Maakt dit dan ook weer niet traag met het zoeken binnen je geheugen block?

[Refro]

Jeanpaul145 schreef op maandag 29 oktober 2007 @ 17:43:
[...]

Ik denk dat er vanuit een developer's perspective alleen nog reden is om met assembly te werken als je aan compilerdevelopment doet.

Dat ligt volkomen aan de soort ontwikkeling die je doet als je echt embedded werkt ontkom je er ook niet aan. De startup code om je C op te starten is gewoon assembly. Ook voor BSP/Driver development in bijvoorbeeld windows CE onkom je er niet aan. Maar voor applicatie development in een ruime omgeving is het inderdaad achterhaalt.

[Marcj]

farlane schreef op maandag 29 oktober 2007 @ 16:18:
[...]


Dat bewijst dat de ontwerper van het C++ programma bagger werk heeft geleverd. Om in C++ een programma te schrijven dat 500x langzamer is dan een vergelijkbaar Java programma moet je toch wel erg veel lagen bouwen. ( met in elke laag een sleep volgens mij )

Toch is het wel waar. Nu is dit wel een extreem geval waar meerdere dingen niet efficient zijn geimplementeerd. Gedeeltelijk lag het echter wel aan het ontwerp. Hierin zat bijvoorbeeld een SearchAlgorthim klasse die verantwoordelijk was voor het doorzoeken van een graaf. Deze had echter verschillende objecten nodig om te bepalen in welke volgorde alles ging gebeuren (DFS of BFS of nog een andere?). Plus dat er tussen deze objecten nog vele 'berichten' werden gestuurd. Er werden nogal veel objecten gegenereerd op runtime, waardoor C++ toch aardig traag werd. Ik heb dit geimplementeerd door SearchAlgorithm een abstracte klasse te maken waarvan de DFS en BFS verschillende implementaties zijn. Hierdoor worden al die berichten gewoon functieaanroepen.

Daarnaast lag een groot gedeelte ook aan de manier waarop tussenresultaten werden opgeslagen. Maar desondanks denk ik dat toch een factor 10 of meer verspilt werd aan 'overdesigning'. Er worden gewoon veel te veel kleine klassen gemaakt die ieders te weinig verantwoordelijkheid hebben...

[RobIII]

Ik denk dat we allemaal wel weten dat assembly nog wel de nodige toepassingen heeft, laten we ophouden met daar over te nitpicken. We weten namelijk ook dat het domein erg klein begint te worden en dat het dus (net zoals zoveel andere technieken) tegenwoordig bijna puur specialistisch wordt toegepast.

[EfBe]

eghie schreef op maandag 29 oktober 2007 @ 19:35:
Klopt. Over het algemeen is de boel omzetten naar assembler niet rendabel genoeg en kun je beter naar andere optimalisaties kijken. Maar ik zie hier ook een aantal reacties nu, waarbij ze op een embedded platform werken, waarbij dat wel veel scheelt. Vanwege waarschijnlijk de abstractie die er in de taal zit (JAVA bijvoorbeed).

Onzin, zolang je niets gemeten hebt en hebt aangetoond wat traag is kun je wel uitspraken doen als 'over het algemeen is lalala' en dat er een abstractielaag tussen code en de hardware zit, maar het blijft lulkoek totdat keiharde meetresultaten uitwijzen dat je gelijk hebt.

Uiteraard zijn er zat verschillende mogelijkheden die bepalen hoe een bepaalde applicatie is, maar richtlijnen opzich zelf zijn er wel lijkt me. Je kunt wel met bepaalde dingen rekening houden, bijvoorbeeld references/pointers gebruiken ipv elke variable kopieeren naar een nieuwe variable als je ermee gaat werken en dan weer terug kopieeren. Dat scheelt wel in de resources.

Maar alleen als je hebt aangetoond dat die moeite het loont EN dat je die consessie wilt doen! Dat zijn vereisten alvorens dit soort code te gaan schrijven, want het kan heel goed zijn dat deze optimalisatie geen moer uitmaakt en dan heb je wel je code minder 'optimaal' gemaakt voor leesbaarheid en begrijpbaarheid.

Om dit op te lossen alloceren sommige applicaties aan het begin al hun geheugen waardoor ze dat niet meer hoeven te doen. Scheelt wel weer in alloceren, alleen geef je meteen wel erg veel geheugen weg aan je app en zit je eigenlijk aan een limiet voor geheugen. Uiteraard kun je alsnog meer alloceren wanneer nodig. Maakt dit dan ook weer niet traag met het zoeken binnen je geheugen block?

In VM platforms is object allocation soms duurder dan verwacht, omdat je de GC veelal vergeet toe te voegen aan je totaalplaatje, plus dat het in de talen veelal ongemerkt gaat, het alloceren van objects, terwijl als je naar de trees kijkt van objects in memory dan schrik je je soms een hoedje.

[Glimi]

RobIII schreef op maandag 29 oktober 2007 @ 10:52:
...
Anyway; ik wil hier wel even een keer van de mythe af dat (hand-coded) assembly sneller zou zijn dan code van een hoge(re) taal als C++, C#, Java of whatever. In principe zou dat moeten kunnen/zijn, echter met de complexiteit van de huidige processors (en dan heb ik het over branche-prediction, pipeline optimalisations, cache levels etc. et.c) kun je als 'human' haast niet meer op tegen een compiler die een 3GL of hoger omzet naar een binary; een compiler weet (zeker als het toegesneden is op een bepaalde CPU) veel beter gebruik te maken van dit soort optimalisaties dan je zelf zou kunnen. Natuurlijk kun je uitgepoepte code nog wat proberen te optimizen maar dan moet je al verrekkes goed weten waar je mee bezig bent.
...

Je overschat hierbij de gegenereerde code van een compiler wel aardig. Je haalt bijv de branche predictor aan; hier is weinig officiele documentatie over te verkrijgen. Alle informatie die ik heb kunnen vinden komt van tests af van Agner Fog. Daaruit blijkt dat de implementatie van de branchpredictor verschillend is tussen _alle_ generaties van x86 cpu's. Van global saturating counters tot hashmaps van counters. Geen enkele compiler, op de intel compiler na (en dat is zelfs een gok) zal hier rekening mee houden en zich aan een paar stelregels houden.
1) De eerste keer dat we een branch tegen komen wordt ie standaard predicted als 'niet genomen'
2) Indirecte jumps zijn vreselijk duur op moderne architecturen
Verder begreep ik van .oisyn dat er weing tot geen compilers zijn die SSE* instructies gebruiken voor math. Kortom, zo'n genie hoef je niet te zijn om betere ASM te schrijven dan GCC zal genereren.

[.oisyn]

Glimi schreef op maandag 29 oktober 2007 @ 22:24:
Verder begreep ik van .oisyn dat er weing tot geen compilers zijn die SSE* instructies gebruiken voor math. Kortom, zo'n genie hoef je niet te zijn om betere ASM te schrijven dan GCC zal genereren.

Dat moet ik iets nuanceren. VC++ kan bijvoorbeeld float operaties volledig met SSE implementeren, maar gebruikt daar alleen de scalar varianten van SSE instructies voor (die dus alleen op het "x" component in elk register werken). Dit zal een JIT compiler natuurlijk ook gemakkelijk kunnen. Ook bieden de meeste compilers (Intel, VC++, gcc) wel zogenaamde intrinsics om op C/C++ niveau de SSE instructies toe te passen, alsmede speciale types om aan te geven dat een variabele op een SSE register moet mappen.

De uitspraak die ik gedaan heb die jij aanhaalt was waarschijnlijk een uit de context of een managed taal net zo snel kan zijn als een native C++ applicatie, waarbij ik zeg: nee, waarschijnlijk niet, omdat ik nog geen enkele (JIT of native) compiler heb gezien die willekeurige float operaties kan vectorizen naar SIMD instructies, en omdat je met C++ gebruik kunt maken van intrinsics zullen de VM talen dus achter blijven, tenzij ze daar native support voor inbouwen (zoals bijvoorbeeld een speciaal vector datatype)

[farlane]

EfBe schreef op maandag 29 oktober 2007 @ 20:32:
Onzin, zolang je niets gemeten hebt en hebt aangetoond wat traag is kun je wel uitspraken doen als 'over het algemeen is lalala' en dat er een abstractielaag tussen code en de hardware zit, maar het blijft lulkoek totdat keiharde meetresultaten uitwijzen dat je gelijk hebt.

Mjah toch vind ik de aanname niet zo heel gek, ook al kan ik het niet met cijfers onderbouwen. Ben eigenlijk wel benieuwd of je een voorbeeld weet van een abstractielaag die juist een snelheidsverbetering laat zien?

[LauPro]

EfBe schreef op maandag 29 oktober 2007 @ 20:32:
Onzin, zolang je niets gemeten hebt en hebt aangetoond wat traag is kun je wel uitspraken doen als 'over het algemeen is lalala' en dat er een abstractielaag tussen code en de hardware zit, maar het blijft lulkoek totdat keiharde meetresultaten uitwijzen dat je gelijk hebt.

Een profiler is een tool voor als het eigenlijk al te laat is. Het is een logisch proces en veelal heeft (projecttechnisch gezien) functionaliteit meer prioriteit dan responsiteit. Toch kan je als programmeur van veel calls op je klompen aanvoelen dat iets veel I/O gaat veroorzaken (dus afhankelijkheid en latentie).

Ik denk dat de enige meest logische conclusie van dit topic is: spreek zo min mogelijk resources aan en benader dit vanuit het platform, de toolkit, applicatie en de user.

GTK is gewoon een enorm lompe toolkit, dit maakt FF en OOo zo traag met opstarten. Opera en KDE daarintegen zijn gebaseerd op QT welke supersnel is, lichtgewicht in C++ geschreven toolkit. Welke zelfs mogelijkheden tot OpenGL heeft.[/spam]

[.oisyn]

Wat heeft OpenGL er in hemelsnaam mee te maken?

[Skinkie]

LauPro schreef op dinsdag 30 oktober 2007 @ 00:38:
GTK is gewoon een enorm lompe toolkit, dit maakt FF en OOo zo traag met opstarten. Opera en KDE daarintegen zijn gebaseerd op QT welke supersnel is, lichtgewicht in C++ geschreven toolkit. Welke zelfs mogelijkheden tot OpenGL heeft.[/spam]

uuhh wat Check voor de gein eens met strace wat er voordat er maar een letter op je scherm staat gebeurd met een QT programma en een GTK programma. GTK traag laat me niet lachen

Wat heeft OOo overigens met GTK te maken?


nog even inhoudelijk:

Wat maakt een app snel?

Zo veel mogelijk zaken door het OS laten doen. Neem als voorbeeld bestanden openen. Er zijn individuen die nog steeds fopen etc. gebruiken om bestanden in te lezen. Waarom gebruikt men niet de een van de mooiste functies van de afgelopen jaren: mmap. Minder gezeur, direct toegang tot de data, mogelijkheid om pages te definiëren. Echt ik zou geen enkele reden meer weten waarom ik ooit nog fopen zou willen gebruiken.

Vermijden van innerloops is natuurlijk ook weer zoiets, maar dat is puur nadenken voordat je iets gaat programmeren. In de zelfde orde van grootte: sorteren, zoeken doe je niet op een ongesorteerde lijst, zeker niet als je het vaker gaat doen.


Wat maakt een app interactief?

Er voorzorgen dat je threading gebruikt waar je het kan toepassen. Niets is zo zinloos als je 'frontend' laten wachten op zaken terwijl je backend wat aan het doen is.


Tip voor thuis:

Profile je applicatie, dan zie je wat het meeste tijd kost, en met alles meer dan 10% van de tijd opneemt kun je met optimalizatie een flinke snelheids boost maken.

[ Voor 48% gewijzigd door Skinkie op 30-10-2007 01:34 ]

[LauPro]

.oisyn schreef op dinsdag 30 oktober 2007 @ 01:22:
Wat heeft OpenGL er in hemelsnaam mee te maken?

Niets, maar was even een eigen inbreng ter promotie van de QT toolkit (vandaar de spam tag), en zelfs een toolkit die een lage footprint heeft met veel functies.

Skinkie schreef op dinsdag 30 oktober 2007 @ 01:26:
uuhh wat Check voor de gein eens met strace wat er voordat er maar een letter op je scherm staat gebeurd met een QT programma en een GTK programma. GTK traag laat me niet lachen

We hebben het hier niet over een hello world applicatie maar bijvoorbeeld een development IDE of tekstverwerker. GTK heeft dan tov QT een hele grote footprint.

Wat heeft OOo overigens met GTK te maken?

Afaik is het UI-project van OOo gebaseerd op GTK en gebruiken veel platforms de GTK file helpers e.d.. Anders zou je voor de gein maar eens iets moeten pakken als AbiWorld tegen KOffice af moeten zetten. We hebben het over seconden veelal. Al moet ik zeggen dat met goede prelinking veel valt te behalen.

Verder is er toch een levend voorbeeld gewoon?
• Firefox: GTK
• Opera: QT

Het verhaal over de XUL e.d. is imo minor. Het grootste probleem blijft de renderengine die alle GTK overhead met zich meedraagt. Maargoed, is een andere discussie.

Kern van de zaak is, goede libraries/platforms gebruiken die het OS ontlasten van de meest basic calls en de applicatie het gemak geven.

[.oisyn]

LauPro schreef op dinsdag 30 oktober 2007 @ 01:59:
[...]
Niets, maar was even een eigen inbreng ter promotie van de QT toolkit (vandaar de spam tag), en zelfs een toolkit die een lage footprint heeft met veel functies.

Heb je aandelen Qt oid? Ik vind het trouwens een boutlibrary, omdat je er een aparte compiler voor nodig hebt.

[q]Verder is er toch een levend voorbeeld gewoon?
• Firefox: GTK
• Opera: QT
Ja, twee random voorbeelden zeggen idd alles over GTK en Qt

[Mathijs1]

Wat ik merk is dat er vooral bij op-maat-gemaakte bedrijfssoftware erg doelgericht gewerkt wordt, in plaats van middel-gewerkt (als er al zo'n term bestaat). Slimme datastructuren en snelle algoritmes worden vaak vergeten als er een deadline aankomt of er de zoveelste specificatiewijziging binnenkomt.

Als je een hobby-ist projectje bekijkt van iemand die het op vrijwillige basis maakt (en deze persoon heeft genoeg kennis van zaken) dan zal hij al gauw een sneller alternatief van een heleboel bestaande software kunnen maken.

Of je dit nou direct kunt afleiden tussen commerciële- en opensource-software weet ik niet, dat soort uitspraken zijn me iets te gevaarijk

[LauPro]

.oisyn schreef op dinsdag 30 oktober 2007 @ 02:05:
Heb je aandelen Qt oid? Ik vind het trouwens een boutlibrary, omdat je er een aparte compiler voor nodig hebt.

Geen aandelen nog helaas, aparte compiler, bedoel je build system? Er zijn vrij weinig andere C++ based cross platform toolkits.

Ja, twee random voorbeelden zeggen idd alles over GTK en Qt

Het is meer een algemene tendens die ik zie.

[Verwijderd]

De hele clou van het verhaal blijft toch dat mensen gewoonweg duurder zijn dan machines, en dat het absoluut geen zin heeft om je tijd in al te veel optimalisaties te steken. De oplossing voor te trage applicaties is bijna overal: betere hardware. Niet uit luiheid, maar gewoon omdat het goedkoper is.
En ja, uiteraard moet je wat fatsoenlijk programmeren, maar grof genomen is optimaliseren zelfs nadat de applicatie af is verspilde tijd. Zelfs in de uiterst tijdskritische bankwereld is de oplossing voor een te trage app niet aan de app gaan sleutelen, maar ze naar de z-series schruiven
Verder is, zoals al eerder aangehaald, een traag backend iets totaal anders dan een trage (of traag aanvoelende) frontend. En ja, daar moet je inderdaad de HCI principes toepassen: geef de user feedback over wat er gebeurd.

[_Thanatos_]

Maar mensen, snelheid van een applicatie is niet alleen puur hoe effecient de applicatie met de beschikbare rekenkracht omgaat (tenzij het een CPU-intensieve taak betreft), maar voornamelijk hoe snel en efficient een gebruiker met de applicatie om kan gaan.

Hier komen dan gelijk allerlei usability-issues om de hoek kijken, die misschien voor dit topic minder interessant zijn om te bespreken, maar het feit is wel dat Notepad misschien een retesnelle tool is, toch kan ik in een goeie HTML editor, hoe lomp die ook is, veel sneller een webpagina in elkaar klussen.

Dat lijkt me duidelijk. Maar stel nu dat die HTML editor geoptimaliseerd werd (optimize for speed aanzetten, assembly code - voor de onderhoudbaarheid - en weet ik wat voor slimme algortimes erin bakken). Dat neemt niet weg dat ik nog steeds 99% van de tijd bezig bent met het typen van content.

[ Voor 20% gewijzigd door _Thanatos_ op 30-10-2007 04:05 ]

[LDenninger]

hebben we het nou over performance,
of over perceptie van performance ?

Ik had vroeger een diskdefragmenter die veel sneller leek dan een andere, omdat ie veel meer reads en writes liet zien. Dat ie daardoor in feite trager werd vanwege de vele screen-updates had ik pas veel later door, maar hij leek veel sneller

[ Voor 61% gewijzigd door LDenninger op 30-10-2007 06:48 ]

[Exirion]

LauPro schreef op dinsdag 30 oktober 2007 @ 00:38:
GTK is gewoon een enorm lompe toolkit, dit maakt FF en OOo zo traag met opstarten. Opera en KDE daarintegen zijn gebaseerd op QT welke supersnel is, lichtgewicht in C++ geschreven toolkit. Welke zelfs mogelijkheden tot OpenGL heeft.[/spam]

Wat een gelul. Als er een toolkit lomp en traag is, dan is het QT wel. Ga maar eens spelen met QTopia op een embedded platform (waar het notabene voor bedoeld is). Bovendien is C++ juist _trager_ dan C, waarin GTK geschreven is. En als je goed op de hoogte was dan zou je weten dat GTK in de laatste versies gebaseerd is op de Cairo library die als onderliggende laag Glitz heeft die een abstractie van OpenGL vormt. GTK ondersteunt dus net zo goed OpenGL en ik kan je uit ervaring zeggen dat GTK echt duidelijk sneller is dan QT. Ik loop regelmatig te vloeken over hoe lomp QT is, en ze maken er ook een sport van om bij elk subversie weer dingen in de API te wijzigen

[netvor]

LauPro schreef op dinsdag 30 oktober 2007 @ 00:38:
GTK is gewoon een enorm lompe toolkit, dit maakt FF en OOo zo traag met opstarten. Opera en KDE daarintegen zijn gebaseerd op QT welke supersnel is, lichtgewicht in C++ geschreven toolkit. Welke zelfs mogelijkheden tot OpenGL heeft.[/spam]

Opera is niet gebaseerd op Qt. Opera is snel omdat de UI zoveel mogelijk met native calls wordt getekend. AFAIK vraagt Opera het onderliggende platform om een canvas voor de HTML renderer en worden de menubalkjes e.d. natively afgehandeld.
Alleen de Linux-versie van Opera gebruikt Qt. En daar wordt Qt alleen gebruikt om een canvas voor de HTML renderer te krijgen.
Verder is Opera snel omdat er geen plugin-mechanisme zoals bij Firefox bestaat. Alles zit in een enkele executable ingebakken.

Tot slot over Qt: ik vind het een prettige library om voor te ontwikkelen, maar net als bij GTK/WxWdigets/Swing/whatever geldt: supersnel is het niet. Als ik Opera vergelijk met Konqueror en Skype (Qt apps) dan weet ik wel welke de snellere is.

[EfBe]

LauPro schreef op dinsdag 30 oktober 2007 @ 00:38:
[...]
Een profiler is een tool voor als het eigenlijk al te laat is. Het is een logisch proces en veelal heeft (projecttechnisch gezien) functionaliteit meer prioriteit dan responsiteit. Toch kan je als programmeur van veel calls op je klompen aanvoelen dat iets veel I/O gaat veroorzaken (dus afhankelijkheid en latentie).

Lees mijn 1e post in dit topic maar, daar leg ik uit dat er een volgorde zit in het toepassen van technieken. Een profiler is helemaal niet een tool voor als het te laat is, sterker het is een tool voor precies dat waar ze voor bedacht zijn: meten WAT nu eigenlijk traag is in de applicatie. Als je een checkbox uitvinkt en er gaan 1001 events af en die triggeren allemaal redraws dan zal de checkbox uitvink actie erg traag lijken, maar jij weet echt niet waarom. Een profiler zal je vertellen waar het aan ligt.

Kennelijk heb jij nog nooit de eis gehad dat je code zo snel mogelijk zou moeten zijn, immers dan had je geweten dat een profiler een essentieel onderdeel is van de gereedschappen die je gebruikt om je code zo snel mogelijk te maken. Als je niet weet WAT traag is, zul je t.a.t. maar wat aanrommelen op goed geluk.

En sorry dat ik het zeg, maar 'op de klompen aanvoelen' en aanverwante zaken: ik vind het lulkoek van de bovenste plank: ga eerst nadenken over algorithmes, dan implementeer je die algoritmes, dan ga je profilen, optimizen, profilen, optimizen, etc. en dan ben je klaar en niet eerder.

Ik denk dat de enige meest logische conclusie van dit topic is: spreek zo min mogelijk resources aan en benader dit vanuit het platform, de toolkit, applicatie en de user.

Nee, dat is dus de VERKEERDE conclusie. Ten eerste zeg jij niets over het te kiezen setje algoritmes, wat het leeuwendeel van je optimalisatie inhoudt, en ten tweede zeg jij niets over meten. Wat uit de losse pols nadenken over welke code nu sneller zou kunnen en hoe dat dan met truuks op de vierkante millimeter moet worden rechtgeknoeid... dat heeft echt geen enkele zin. Dan krijg je discussies als 'gebruik een for ipv een foreach, want die is ietsje sneller'.

Het enige punt dat ik jou wil geven is de user-perceptie van snel/traag en dat is een vaak vergeten ding. Splashscreens zijn daar een goed voorbeeld van: als je een traag startende app geen splashscreen geeft dan gaat de user denken "hij hangt!" of "wat traag!", maar als je er een splashscreen in stopt is het ineens een normaal iets.

Verwijderd schreef op dinsdag 30 oktober 2007 @ 02:38:
De hele clou van het verhaal blijft toch dat mensen gewoonweg duurder zijn dan machines, en dat het absoluut geen zin heeft om je tijd in al te veel optimalisaties te steken. De oplossing voor te trage applicaties is bijna overal: betere hardware. Niet uit luiheid, maar gewoon omdat het goedkoper is.

Ja, wel uit luiheid. Veelal is het optimaliseren van een applicatie helemaal niet zoveel werk, immers je had al VOORAF de snelste algoritmes uitgekozen, toch?

Dus als blijkt dat de applicatie gewoon een brak traag design heeft, dan is het een fout van de eerste orde, en in de volksmond noemt men dat gewoon prutswerk. Nee, inderdaad, prutswerk sneller maken levert nog steeds prutswerk op, dan kun je beter veel hardware naar binnenschuiven om trage boutsoftware toch nog wat redelijk te laten draaien, maar ik vind dat de developers die dat overkomt zich dood moeten schamen.

De huidige hardware is zo intens rap dat het echt moeilijk is een trage applicatie te bouwen. Mensen realiseren zich het niet echt, maar 10 jaar terug waren de duurdere servers uitgerust met pentium 200's en die draaiden ook de backoffice van het bedrijf, dus waarom moeten daar nu 4 socket quad core xeon's worden neergezet voor hetzelfde? Om te verbloemen dat het clubje consultants toch niet zo goed bleek als hun dure pakken + leasebakken deed voorkomen?

En ja, uiteraard moet je wat fatsoenlijk programmeren, maar grof genomen is optimaliseren zelfs nadat de applicatie af is verspilde tijd. Zelfs in de uiterst tijdskritische bankwereld is de oplossing voor een te trage app niet aan de app gaan sleutelen, maar ze naar de z-series schruiven

Nee die smiley helpt je niet, ik vind de bovenstaande quote een treurige opmerking. Het punt is nl. dat het aantoont dat men het kennelijk normaal vindt dat bv bij de belastingdienst 4200 (!) mensen werken op de it afdeling die 400 miljoen (!) euro per jaar opvreet en dat ze dan NOG niet in staat zijn programma's te maken die de ene database met de andere koppelen.

Dan moet je niet roepen dat wanneer het niet performt dat IBM's grote dozen het maar moeten opvangen, nee, dan moet je je ogen uit je kop schamen dat je jezelf nog software engineer durft te noemen. Profilen van een applicatie is iets dat hoort bij development, het is een onderdeel van het nakijken of je wel goed werk hebt afgeleverd. Een profiler toont nl. nog meer aan dan alleen trage troepcode: het toont ook aan dat bv sommige delen van je applicatie HEEL erg vaak gebruikt worden en andere delen juist helemaal niet of nauwelijks. Dat is essentieel inzicht in hoe een applicatie onderhouden moet worden en waar in de toekomst problemen verwacht kunnen worden (10 tegen 1 in het gedeelte wat erg vaak gebruikt wordt).

[ Voor 35% gewijzigd door EfBe op 30-10-2007 09:42 ]

[roy-t]

Profilers zijn anders erg interessant vind ik, soms is het gewoon 1 stukje code waar je net liever een ander algoritme had moeten gebruiken juist in die ene specifieke situatie.

Dan pruts je daar een beetje aan, wordt net iets anders gecompiled en hoppa traagste bottleneck is ineens weg waardoor je programma 10% sneller wordt (in het meest optimale geval ofzo )

Ik vraag me eigenlijk af of er gratis profilers zijn voor Visual Studio Express / C#

Want ik heb eigenlijk alleen betaalde gezien en ben er wel benieuwd naar. Ook om te spelen of aanpak 1 sneller is dan aanpak 2, in een vrij prille designfase is interresant.

[netvor]

Een mooie toevoeging is trouwens ook profilers die het geheugengebruik van een app meten. Ik heb laatst valgrind ontdekt; ik heb wat (oudere) software erdoorheen gehaald (Firefox 1.0.x anyone? ) en je verbaast je erover hoeveel memory leaks je soms tegenkomt.

Dat is dan trouwens wel weer een voordeel van VM's met GC: een prutser die zijn datastructuren niet opruimt kan geen enorme memory leak veroorzaken.

[.oisyn]

You're kidding, right? Als je denkt dat je met een GC geen mem kunt leaken zit je er goed naast.

[ Voor 68% gewijzigd door .oisyn op 30-10-2007 11:26 ]

[Glimi]

netvor schreef op dinsdag 30 oktober 2007 @ 11:24:
Een mooie toevoeging is trouwens ook profilers die het geheugengebruik van een app meten. Ik heb laatst valgrind ontdekt; ik heb wat (oudere) software erdoorheen gehaald (Firefox 1.0.x anyone? ) en je verbaast je erover hoeveel memory leaks je soms tegenkomt.
[..]

Als je de stable draait (3.2.3) dan kom je nogal wat false positives tegen, vooral als firefox tegen een recente glibc aangecompileert is (waar nog geen suppressions voor waren). De head van Valgrind is een stuk beter.

[Jeanpaul145]

leuk_he schreef op maandag 29 oktober 2007 @ 17:59:
[...]


Dat betekent 3 dingen:
-Dat je geen spellingscontrole in je browser hebt.
-Dat het Engels is, je had Nederlands kunnen gebruiken..


En bovenal de quote is langer...

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." and I agree with this. Its usually not worth spending a lot of time micro-optimizing code before its obvious where the performance bottlenecks are.

Je moet je MEESTALin het begin niet te druk maken over kleine optimalisaties.

optimalisation is prima engels, er is een verschil in spelling tussen Engels en Amerikaans Engels he...
Net zoals color en colour.
Als ik een quote hoor in t Engels quote ik 'm ook in t Engels
En idd is de quote misschien langer, maar dit is t relevante stuk.

[Jeanpaul145]

Glimi schreef op maandag 29 oktober 2007 @ 17:52:
[...]
In mijn mening is dat geen universele regel, maar alleen een guideline om je aan het begin van het process niet te laten verleiden om micro-optimalisaties te doen. Maar als jij een sequentiele een lijst afloopt, waar je af en toe elementen uit moet verwijderen dan kies ik voor een LinkedList implementatie en niet voor een ArrayList, ook al kunnen ze hetzelfde.

Maar dat vind ik ook geen optimalisatie, ik vind dat simpelweg NADENKEN over t ontwerp op implementatieniveau

.oisyn schreef op maandag 29 oktober 2007 @ 18:54:
[...]

Er wordt nog zat in assembly gedaan hoor. In de gamedevelopment bijv, maar denk ook aan grafische filters e.d., die hand-optimized SSE code bevatten. Goed, veel is het niet, het draait meestal alleen om de kleine inner loops die gigantische veel worden aangeroepen, maar het wordt weldegelijk nog altijd toegepast.


[...]

Ja, in die zin dat ik het er niet mee eens ben in de hoedanigheid dat jij 'm hier quote. Ga jij achteraf maar eens fijn 100 abstractielagen weg zitten werken om de applicatie beter te laten performen - dan kun je 'm net zo goed meteen helemaal herschrijven

Als jij 100 abstactielagen weg moet zitten werken in je apps heb je iets fundamenteel fout gedaan lijkt me

[ Voor 40% gewijzigd door Jeanpaul145 op 30-10-2007 11:33 ]

[EfBe]

therat10430 schreef op dinsdag 30 oktober 2007 @ 09:57:
Ik vraag me eigenlijk af of er gratis profilers zijn voor Visual Studio Express / C#

nprof http://sourceforge.net/projects/nprof/

geen idee of het nog wordt onderhouden, het is wel een aardige profiler. Ikzelf gebruik altijd Ants van Red Gate, omdat de jetbrains profiler soms wat bugt.

De profiler van MS zelf in vs.net 2005 is overigens ook niet slecht, althans voor het opsporen van memory allocations op bepaalde plekken en hoeveel daarvan nog steeds alive is bv.

[Voutloos]

Jeanpaul145 schreef op dinsdag 30 oktober 2007 @ 11:29:
[...]
optimalisation is prima engels, er is een verschil in spelling tussen Engels en Amerikaans Engels he...

Nope, dat is dus echt geen prima spelling. Het moet optimization (of met een s natuurlijk) zijn.

[Remus]

In mijn ogen geeft een applicatie vooral een snel gevoel als de userinterface snel reageert, in Java is het bijvoorbeeld zaak langdurige acties (> 0,5 s) zsm uit te besteden aan andere thread (bijvoorbeeld met een SwingWorker of een Executor). Hierdoor blijft de interface reageren en komt het dus snel over op de eindgebruiker.

In een aantal posts wordt aangehaald dat een garbage collect voor pauzes kan zorgen. Dat kan kloppen, maar daar valt op te optimaliseren door de juiste parameters mee te geven aan de JVM, daarnaast zijn er op een multicore diverse andere garbagecollection strategiën (parallel, of concurrent-mark-and-sweep). Door de juiste configuratie kunnen de pauzes geminimaliseerd worden of zelfs wegvallen.

[Verwijderd]

EfBe schreef op dinsdag 30 oktober 2007 @ 09:28:
[...]

De huidige hardware is zo intens rap dat het echt moeilijk is een trage applicatie te bouwen. Mensen realiseren zich het niet echt, maar 10 jaar terug waren de duurdere servers uitgerust met pentium 200's en die draaiden ook de backoffice van het bedrijf, dus waarom moeten daar nu 4 socket quad core xeon's worden neergezet voor hetzelfde? Om te verbloemen dat het clubje consultants toch niet zo goed bleek als hun dure pakken + leasebakken deed voorkomen?

Deels heb je daar zeker gelijk mee. Je kan jezelf wel wat bijleren door wat op ARM of op telefoon te ontwikkelen. En ja, een profiler is een belangrijk instrument om te gebruiken als je een applicatie ontwikkeld. Echter, mijn punt was: je moet altijd kijken naar de totale kost, en als je een applicatie hebt die goed ontwikkeld is, maar toch te traag, is het vaak een pak goedkoper van die gewoon op stevigere hardware te gaan draaien, dan om micro-optimalisaties te gaan uitvoeren.

[...]

Nee die smiley helpt je niet, ik vind de bovenstaande quote een treurige opmerking. Het punt is nl. dat het aantoont dat men het kennelijk normaal vindt dat bv bij de belastingdienst 4200 (!) mensen werken op de it afdeling die 400 miljoen (!) euro per jaar opvreet en dat ze dan NOG niet in staat zijn programma's te maken die de ene database met de andere koppelen.

Dan moet je niet roepen dat wanneer het niet performt dat IBM's grote dozen het maar moeten opvangen, nee, dan moet je je ogen uit je kop schamen dat je jezelf nog software engineer durft te noemen. Profilen van een applicatie is iets dat hoort bij development, het is een onderdeel van het nakijken of je wel goed werk hebt afgeleverd. Een profiler toont nl. nog meer aan dan alleen trage troepcode: het toont ook aan dat bv sommige delen van je applicatie HEEL erg vaak gebruikt worden en andere delen juist helemaal niet of nauwelijks. Dat is essentieel inzicht in hoe een applicatie onderhouden moet worden en waar in de toekomst problemen verwacht kunnen worden (10 tegen 1 in het gedeelte wat erg vaak gebruikt wordt).

Ok, daar heb je even mijn verhaal niet begrepen. Die belastingsdienst kost belachelijk veel geld, en dat is net wat je moet vermijden. En nee, ik vind dat absoluut niet normaal. Als je veel mensen nodig hebt om je app te onderhouden is ze per definitie slecht gemaakt.
Mijn hele punt was nu net dat je naar de totale kost moet kijken. En dat als je daar goed naar kijkt, je gaat zien dat mensen een pak duurder zijn dan machines. Gevolg: je moet er rekening mee houden bij het bouwen van je software. En ik zeg dus absoluut niet dat je geen profiler moet gebruiken, mijn enige punt is, dat als een applicatie goed ontwikkeld is (en een profiler gebruiken kan een onderdeel zijn van een app goed te ontwikkelen) dat het dan meestal weinig zin heeft om je nog achteraf met optimalisaties te gaan bezig houden, omdat het gewoon belachelijk veel geld kost.

[YopY]

netvor schreef op dinsdag 30 oktober 2007 @ 11:24:
Dat is dan trouwens wel weer een voordeel van VM's met GC: een prutser die zijn datastructuren niet opruimt kan geen enorme memory leak veroorzaken.

Jawel hoor. Het punt van een GC is dat 'ie geheugen opruimt indien er niets meer aan refereert. Zolang er dus nog een verwijzing naar (bijvoorbeeld) een object in een datastructuur staat, wordt die nooit opgeruimd door de GC; zolang de verwijzing er is, blijft het object in het geheugen.

Een memory leak heb je wanneer je de referentie wegraakt zonder het object eerst vrij te geven, maw, je laat een object in het geheugen zonder dat er een referentie naar is (oftewel, het is er wel, maar je kunt er niet meer bij).

[The End]

EfBe schreef op dinsdag 30 oktober 2007 @ 09:28:
Lees mijn 1e post in dit topic maar, daar leg ik uit dat er een volgorde zit in het toepassen van technieken. Een profiler is helemaal niet een tool voor als het te laat is, sterker het is een tool voor precies dat waar ze voor bedacht zijn: meten WAT nu eigenlijk traag is in de applicatie. Als je een checkbox uitvinkt en er gaan 1001 events af en die triggeren allemaal redraws dan zal de checkbox uitvink actie erg traag lijken, maar jij weet echt niet waarom. Een profiler zal je vertellen waar het aan ligt.

Volgens mij is dat ook een kwestie van een goed ontwerp. Dat soort dingen kan je toch van te voren bedenken? Het lijkt me niet een goed idee om een applicatie die bijna af is half af te gaan breken, omdat tijdens het ontwerp geen rekening met performance is gehouden.

Ik moet eerlijk zeggen dat ik nog nooit een profiler heb gebruikt en dat ik precies weet welke acties traag zijn en waarom.

[.oisyn]

Jeanpaul145 schreef op dinsdag 30 oktober 2007 @ 11:31:
Als jij 100 abstactielagen weg moet zitten werken in je apps heb je iets fundamenteel fout gedaan lijkt me

Bingo! Dus waar let je dan op als je je app designt? Dat 100 abstractielagen wellicht mooi en elegant is (goed, 100 is natuurlijk overdreven, maar you get the drift), maar niet heel erg snel zal performen, en dus gebruik je dat niet. Hence de opmerking dat "Premature optimization is the root of all evil" (in die hoedanigheid) onjuist is. Het gebruiken van 1 abstractielaag ipv 100 is óók een optimalisatie.

The End schreef op dinsdag 30 oktober 2007 @ 12:06:
Ik moet eerlijk zeggen dat ik nog nooit een profiler heb gebruikt en dat ik precies weet welke acties traag zijn en waarom.

Als jij nog nooit een profiler hebt gebruikt dan weet je amper wat, naast natte vinger werk en onderbuik gevoel. De dingen die jij weet, zijn van de algoritmische aard, en als je de posts van EfBe goed hebt gelezen en opgevolgd dan heb je die al getackled bij het designen van je applicatie, en die zul je dus ook niet meer hoeven op te lossen tijdens het profilen.

Waar de profiler je bij gaat helpen zijn resource stalls, cache coherency issues en vooral in welk deel van de code deze het meest optreden. Als jij nog nooit een profiler hebt gebruikt (je code timen met custom timing is ook profiling!) snap je ook niet dat een lineaire search of een bubblesort in sommige gevallen sneller is dan resp. een binary seach of een quicksort, of dat het niet handig is een volatile if in een inner-loop te plaatsen.

[ Voor 91% gewijzigd door .oisyn op 30-10-2007 12:36 ]

[EfBe]

The End schreef op dinsdag 30 oktober 2007 @ 12:06:
Volgens mij is dat ook een kwestie van een goed ontwerp. Dat soort dingen kan je toch van te voren bedenken? Het lijkt me niet een goed idee om een applicatie die bijna af is half af te gaan breken, omdat tijdens het ontwerp geen rekening met performance is gehouden.

Als je je software goed ontwikkelt, dan besteed je aandacht aan de keuze van algoritmes en wel tot in het kleinste detail. Immers: zolang je over algoritmekeuze nadenkt is het veel flexibeler om te switchen naar een andere, je hebt immers nog geen code.

Tuurlijk houden sommigen geen rekening met performance, die denken 'het loopt wel los' en dan blijkt ineens dat iedere webpage 50 queries of meer uitvoert en alles piepend tot stilstand komt op de rokende server van de klant. Echter, dat is gewoon amateurisme, je moet nl. altijd rekening houden met performance, alleen, en dat heb ik duidelijk aangegeven in mn 1e post, er zijn grenzen waarbinnen het redelijk is consessies te doen om performance te winnen, en die grenzen moet je zelf aangeven, want een consessie doen heeft altijd nadelen. Dus heb je die grenzen gesteld (en dat kan prima inhouden: GEEN consessies doen om performance te winnen), en met die grenzen in de hand je programmatuur ontworpen en het blijkt dan te traag, dan is wellicht de enige optie (naast vertrekken naar een ver land ) meer/snellere hardware. Maar niet eerder, IMHO.

Ik moet eerlijk zeggen dat ik nog nooit een profiler heb gebruikt en dat ik precies weet welke acties traag zijn en waarom.

Profilen is net als debuggen iets wat je moet leren. Het is puur meten, maar de clou zit hem in het interpreteren van de meetgegevens. Je moet ten eerste een eikpunt hebben. Als ik ons eigen o/r mapper framework als voorbeeld neem, dan is het wellicht duidelijk.

Stel, we gaan de performance van onze entity fetch logica meten. Als ik dan 5000 entities in een collection inlaadt, dan kost dat bv 0.5 seconden, van start tot finish (0.5 seconden is een uit de lucht gegrepen waarde, het hangt van de entity grootte af, database snelheid etc.). Nu kan men zeggen: "nou, 0.5 seconden is niet slecht". Maar, dat weet je niet, je hebt een eikpunt nodig. Dus, je pakt bv een alternatief: 5000 rows fetchen in een datatable met dezelfde query. Stel, die code kost van start tot finish maar 0.2 seconden. Dan is de entity fetcher dus mooi veel te traag. Kost die datatable code echter 0.7 seconden, dan is onze code snel.

Laten we aannemen dat de 5000 rows in een datatable fetchen 0.2 seconden kost. Dan ligt het voor de hand om te kijken waar onze code dan 0.3 seconden verliest, immers de datatable code heeft maar 0.2 seconde nodig om de data uit de database te trekken en in een container te stoppen.

Dus je start een profiler en runt nogmaals de 5000 query fetch. (meestal kleinere sets met een profiler omdat een profiler significant tijd kost: iedere call wordt onderschept. Een profiler haalt zn eigen executietijd weer van de tijd af dus je merkt het als het goed is niets van in de meetresultaten). Dan zie je bv dat een routine 5000 keer wordt aangeroepen, te weten de routine die een row uit de data in een entity stopt. Als die routine dan 70% van de tijd uitmaakt, dan weet je dat daar dus de winst te pakken moet zijn, indien nodig. Een profiler laat je in detail zien welke call vanuit die routine, welke regel code de meeste tijd vrat. Je kunt dan op de regel of op de routine nauwkeurig zien welk stukje traag was en welk stukje niet.

Het fascinerende is dat het veelal code is die je niet verwacht. Bv een datareader.IsDBNull() is erg traag. datareader.GetValue()==DBNull.Value is dat weer niet, zelfde resultaat. 3 strings aan elkaar plakken met '+' is sneller dan een stringbuilder maken en ze daarin appenden. Bij 4 niet meer.

Die code ga je normaliter niet zitten omschrijven, totdat je op de regel nauwkeurig hebt gezien dat je profiler duidelijk aangeeft dat bv 20% van de executietijd gespendeerd aan een actie in die regel gaat zitten. Dan is het optimaliseren van die regel dus significant.

Een profiler laat je OOK zien dat je de grenzen bereikt hebt: soms kost de executie gewoon van een serie routines gewoon n seconden en de profiler wijst dan bv uit dat er geen routines zijn die echt steken laten vallen. Je bent dan in principe gewoon klaar, mits je natuurlijk goed hebt nagedacht over je algoritmes, en het zal je verbazen maar erg weinig mensen denken eerst na over hun algoritmes alvorens ze gaan programmeren. Dit blijkt bv uit het feit dat men E&C wil in IDEs terwijl debuggen bv begint met het nakijken of je de algoritmes wel goed hebt geimplementeerd. Maar als je daar al niet over hebt nagedacht valt er niets na te kijken want je code IS je ontwerp.

[The End]

.oisyn schreef op dinsdag 30 oktober 2007 @ 12:22:
Als jij nog nooit een profiler hebt gebruikt dan weet je amper wat, naast natte vinger werk en onderbuik gevoel. De dingen die jij weet, zijn van de algoritmische aard, en als je de posts van EfBe goed hebt gelezen en opgevolgd dan heb je die al getackled bij het designen van je applicatie, en die zul je dus ook niet meer hoeven op te lossen tijdens het profilen.

Beetje onzinnig om dat te zeggen. Het ligt heel erg aan het soort applicatie of profilen van belang is. Applicaties die ik schrijf hoeven geen 1000x per seconden iets te sorteren. Die moeten soms 1x iets sorteren; waarvoor quicksort dan prima werkt. Het grootste deel van het wachten in mijn soort applicatie is netwerk calls. Die kan ik zoveel profilen als ik wil, maar ze worden echt niet sneller.

@Efbe, als ik 1x per dag 5000 rows uit een database moet halen, dan is 0.5 seconden een prima tijd. Zonde om dan tijd te besteden aan het verder optimaliseren van zo'n query.

[.oisyn]

The End schreef op dinsdag 30 oktober 2007 @ 13:31:
[...]

Beetje onzinnig om dat te zeggen. Het ligt heel erg aan het soort applicatie of profilen van belang is.

Ik zeg ook niet dat het van belang is, ik reageer op jouw opmerking dat jij meestal wel weet wat traag is, waarvan ik zeg dat je er eigenlijk helemaal geen weet van hebt als je het niet hebt gemeten.

[eghie]

The End schreef op dinsdag 30 oktober 2007 @ 13:31:
[...]

Beetje onzinnig om dat te zeggen. Het ligt heel erg aan het soort applicatie of profilen van belang is. Applicaties die ik schrijf hoeven geen 1000x per seconden iets te sorteren. Die moeten soms 1x iets sorteren; waarvoor quicksort dan prima werkt. Het grootste deel van het wachten in mijn soort applicatie is netwerk calls. Die kan ik zoveel profilen als ik wil, maar ze worden echt niet sneller.

@Efbe, als ik 1x per dag 5000 rows uit een database moet halen, dan is 0.5 seconden een prima tijd. Zonde om dan tijd te besteden aan het verder optimaliseren van zo'n query.

Netwerk connecties kun je ook optimaliseren. Als bijvoorbeeld roundtrips erg lang duren, zorg je ervoor dat je niet zoveel data heen en weer hoeft te sturen, door bijvoorbeeld alles in 1 keer te sturen. Moet je applicatie op WAN bijvoorbeeld ook goed werken, of is LAN genoeg en dan hoef je daar dan wat minder rekening mee te houden. Ook zou je nog gebruik kunnen maken van caching als dat kan met je data en als het nut heeft. Binnen LAN omgeving is caching vaak niet echt nuttig, omdat de cache zelfs trager kan zijn, maar binnen WAN omgevingen vaak wel.

[ Voor 11% gewijzigd door eghie op 30-10-2007 14:10 ]

[TeeDee]

The End schreef op dinsdag 30 oktober 2007 @ 13:31:
[...]
Beetje onzinnig om dat te zeggen. Het ligt heel erg aan het soort applicatie of profilen van belang is. Applicaties die ik schrijf hoeven geen 1000x per seconden iets te sorteren. Die moeten soms 1x iets sorteren; waarvoor quicksort dan prima werkt. Het grootste deel van het wachten in mijn soort applicatie is netwerk calls. Die kan ik zoveel profilen als ik wil, maar ze worden echt niet sneller.

Even nog een specifiek stukje uit EfBe's betoog:

Als die routine dan 70% van de tijd uitmaakt, dan weet je dat daar dus de winst te pakken moet zijn, indien nodig.

Als je nu van indien nodig eens maakt: indien mogelijk. Moet je altijd die netwerk calls maken of is er verder niet over nagedacht of dit anders kan?

Imo is het natuurlijk wel van belang dat je kijkt of jouw applicatie het echt nodig heeft.

@Efbe, als ik 1x per dag 5000 rows uit een database moet halen, dan is 0.5 seconden een prima tijd. Zonde om dan tijd te besteden aan het verder optimaliseren van zo'n query.

Je pakt nu specifieke opmerkingen, maar ik denk dat je het algehele plaatje misschien niet ziet.

[The End]

.oisyn schreef op dinsdag 30 oktober 2007 @ 13:51:
Ik zeg ook niet dat het van belang is, ik reageer op jouw opmerking dat jij meestal wel weet wat traag is, waarvan ik zeg dat je er eigenlijk helemaal geen weet van hebt als je het niet hebt gemeten.

Je hoeft niet alles te meten om te weten of het traag is. Je kan van veel dingen ook beredeneren of het traag is. (Zoals een vinkje 1000 dingen laten triggeren die allemaal redrawen)

@eghie en Teedee,

Dat is nou juist mijn punt. Ik heb geen profiler nodig om mij te laten zien dat netwerk calls traag zijn. Als ik in mijn ontwerp dus geen rekening houdt met eventuele caching van data, dan is het te laat als ik het zou gaan profilen, omdat ik dan mijn hele ontwerp moet veranderen.

[ Voor 23% gewijzigd door The End op 30-10-2007 14:15 ]

[.oisyn]

Ja, en dat zijn dus dingen van algoritmische aard, waarvan we hadden gesteld dat die al weggewerkt waren. Dan kun je wel roepen dat jij daar geen profiler voor nodig hebt, maar wij zeggen dat tegen de tijd dat je de profiler gebruikt je al niet meer tegen dat soort dingen aan loopt.

[Voutloos]

The End schreef op dinsdag 30 oktober 2007 @ 14:12:
Je hoeft niet alles te meten om te weten of het traag is.

Of andersom: met een profiler hoef je niet alles te weten om het te kunnen meten.

[RedRose]

The End schreef op dinsdag 30 oktober 2007 @ 13:31:
[...]

Beetje onzinnig om dat te zeggen. Het ligt heel erg aan het soort applicatie of profilen van belang is. Applicaties die ik schrijf hoeven geen 1000x per seconden iets te sorteren. Die moeten soms 1x iets sorteren; waarvoor quicksort dan prima werkt. Het grootste deel van het wachten in mijn soort applicatie is netwerk calls. Die kan ik zoveel profilen als ik wil, maar ze worden echt niet sneller.

@Efbe, als ik 1x per dag 5000 rows uit een database moet halen, dan is 0.5 seconden een prima tijd. Zonde om dan tijd te besteden aan het verder optimaliseren van zo'n query.

Het punt is voornamelijk dat je veel beter leert programmeren als je een profiler gebruikt. Natuurlijk hangt het er erg vanaf welke software je schrijft en met welk doel, maar over het algemeen kan je toch wel stellen dat je zo snel en efficient mogelijk wil kunnen programmeren om goede kwaliteit software af te leveren? Een profiler is daarbij imho een essentieel hulpmiddel.

Voorbeeldje: een website met een beetje complexe logica is vrij snel in elkaar te zetten in JSP / PHP, whatever taal. Als je niet veel bezoekers hebt, zal die prima draaien.. Totdat je plotseling 10000 hits per seconde hebt en dan achter je oren gaat zitten krabben waarom het allemaal zo traag is. Tuurlijk, meer servers ertegen aan gooien is een oplossing. Maar profilen en optimaliseren is minstens net zo belangrijk. Het staat alleen een beetje lullig als je dat pas achteraf doet in zo'n geval (denk bijvoorbeeld Fok ) .

Ik vind dus dat je altijd zo optimaal mogelijk en al naar gelang je kennis is moet programmeren. Ook om er zelf beter van te worden.

[The End]

Voutloos schreef op dinsdag 30 oktober 2007 @ 14:16:
[...]
Of andersom: met een profiler hoef je niet alles te weten om het te kunnen meten.

Dan ben je dus te laat. Je moet in de ontwerp fase al weten, anders kun je het niet goed ontwerpen.

@RedRose, het klinkt alsof je het hebt over een hobby projectje. Als je een professionele applicatie schrijft, dan mag ik er toch wel van uit gaan dat je van te voren al rekening houdt met performance?

Even voor de duidelijkheid; ik zei ook dit "Het ligt heel erg aan het soort applicatie of profilen van belang is." Ik zei ook dat het in mijn geval niet nodig was, omdat ik weet wat eventueel traag is. Waarschijnlijk heeft dat ook te maken met het type applicatie wat ik schrijf.

[Refro]

Voutloos schreef op dinsdag 30 oktober 2007 @ 14:16:
[...]
Of andersom: met een profiler hoef je niet alles te weten om het te kunnen meten.

Een profiler is gewoon een mooi stukje gereedschap dat je bevestiging kan geven dat je applicatie snel genoeg is of dat je ergens een performance probleem hebt. Dat je het gevoel hebt bij wat je doet en de mogelijke problemen is goed. Maar zonder harde cijfers kan je er ook weining mee (en mijns inziens ook niets veranderen). Een timmerman meet toch ook voor en na de bewerking aan zijn stuk hout ook al weet hij dat die boomstam echt te dik is om er een tafelpoot van te maken.

[Voutloos]

The End schreef op dinsdag 30 oktober 2007 @ 14:24:
[...]
Dan ben je dus te laat. Je moet in de ontwerp fase al weten, anders kun je het niet goed ontwerpen.

En soms kom je, hoe leuk je ontwerp toch is en hoe slim je jezelf als devver ook vind, toch pas achter een hotspot dmv een profiler. Profilen of schatten waar de meeste cpu tijd (bijvoorbeeld) besteed wordt kan je echt niet altijd aan de hand van een ontwerp.

@RedRose, het klinkt alsof je het hebt over een hobby projectje. Als je een professionele applicatie schrijft, dan mag ik er toch wel van uit gaan dat je van te voren al rekening houdt met performance?

Als je juist niet in retrospectief wil controleren of alles qua performance een beetje jofel is of dat je bottlenecks inderdaad zitten waar je dacht dat ze zouden zitten, heb je imo juist de instelling die alleen bij een hobbyprojectje past.

[The End]

Voutloos schreef op dinsdag 30 oktober 2007 @ 14:32:
En soms kom je, hoe leuk je ontwerp toch is en hoe slim je jezelf als devver ook vind, toch pas achter een hotspot dmv een profiler. Profilen of schatten waar de meeste cpu tijd (bijvoorbeeld) besteed wordt kan je echt niet altijd aan de hand van een ontwerp.

In mijn geval wel.

Als je juist niet in retrospectief wil controleren of alles qua performance een beetje jofel is of dat je bottlenecks inderdaad zitten waar je dacht dat ze zouden zitten, heb je imo juist de instelling die alleen bij een hobbyprojectje past.

Als het goed is test je een applicatie voordat ie gereleased wordt.

[.oisyn]

Ergo, gebrek aan ervaring, want je kan schijnbaar niet buiten je eigen plaatje kijken

[The End]

.oisyn schreef op dinsdag 30 oktober 2007 @ 14:51:
Ergo, gebrek aan ervaring, want je kan schijnbaar niet buiten je eigen plaatje kijken

Onzin man: "Het ligt heel erg aan het soort applicatie of profilen van belang is." Er valt geen reet te profilen in de applicaties die ik schrijf. Ik begrijp heel goed waarom een profiler nuttig zou zijn bij heel veel toepassingen; ik geef echter aan dat het bij mij niet het geval is. Kan jij soms zelf niet buiten je eigen plaatje kijken?

Heel veel applicaties zijn traag, omdat ze slecht ontworpen zijn en/of omdat ze slecht geprogrammeerd zijn. Een profiler is dan niets meer dan een lapmiddel. Je moet een profiler inzetten waar hij voor bedoelt is: optimaliseren van code; niet het fixen van rotte code/ontwerp.

[.oisyn]

The End schreef op dinsdag 30 oktober 2007 @ 14:58:
Ik begrijp heel goed waarom een profiler nuttig zou zijn bij heel veel toepassingen; ik geef echter aan dat het bij mij niet het geval is.

De indruk die je in de topic wekt is echter dat je profilers onzinnig vind "omdat je toch wel kunt bepalen waar de traagheid zit". En als we daar dan op in gaan krijg je reacties als "nou, bij mij niet". Met deze opmerking ben je echter al een stuk genuanceerder.

[EfBe]

The End schreef op dinsdag 30 oktober 2007 @ 13:31:
[...]
@Efbe, als ik 1x per dag 5000 rows uit een database moet halen, dan is 0.5 seconden een prima tijd. Zonde om dan tijd te besteden aan het verder optimaliseren van zo'n query.

Het is niet de query die de performance kost en die je profiled, maar juist de generieke code waarmee je de query uitvoert. Dus is die optimaal, dan is elke query optimaal. Vandaar dat ik dit koos als voorbeeld, omdat het zeker loont om dat te profilen, en aangezien jij het niet doorhad, is het dus zeker een goed voorbeeld geweest, want het voorbeeld diende aan te geven dat profilen loont ookal denk je helemaal niet dat het nuttig KAN zijn.

Dat jij ervan uitgaat dat jouw applicaties niet te profilen zijn want dat is toch niet nuttig, dan moet je jezelf de vraag stellen: is er ERGENS in jouw applicatie ook maar een seconde 'lag' of traagheid? Moet de gebruiker ook maar ergens wachten? Nee? dan heb je gelijk. Indien ja, dan heb je dus ongelijk en is er een hotspot die wellicht niet nu wellicht wel in de toekomst je gaat opbreken

[ Voor 41% gewijzigd door EfBe op 30-10-2007 15:49 ]

[The End]

.oisyn schreef op dinsdag 30 oktober 2007 @ 15:28:
De indruk die je in de topic wekt is echter dat je profilers onzinnig vind "omdat je toch wel kunt bepalen waar de traagheid zit". En als we daar dan op in gaan krijg je reacties als "nou, bij mij niet". Met deze opmerking ben je echter al een stuk genuanceerder.

Ik had het al eerder aangegeven dat het gold voor mijn applicatie. Mijn reactie komt echter ook een beetje, omdat er veel voorbeelden gegeven worden van performance problemen die in de ontwerpfase al voorkomen hadden moeten worden.

In applicaties die ik schrijf treden alleen 'performance' problemen op bij foutsituaties of in specefieke configuraties. (Een server die down is, een server over een trage WAN verbinding, kapotte server enz enz.) Daar moet ik in het ontwerp rekening mee houden. Als ik dat niet doe, dan kan het later niet meer gerepareerd worden. Ik heb geen profiler nodig om te begrijpen dat elke netwerk call die ik doe mogelijk heel traag is of mislukt.

Voor de rest ben ik het wel met je eens hoor, dat een profiler een hele bruikbare tool kan zijn.

EfBe schreef op dinsdag 30 oktober 2007 @ 15:43:
Het is niet de query die de performance kost en die je profiled, maar juist de generieke code waarmee je de query uitvoert. Dus is die optimaal, dan is elke query optimaal. Vandaar dat ik dit koos als voorbeeld, omdat het zeker loont om dat te profilen, en aangezien jij het niet doorhad, is het dus zeker een goed voorbeeld geweest, want het voorbeeld diende aan te geven dat profilen loont ookal denk je helemaal niet dat het nuttig KAN zijn.

Dat is waarschijnlijk een verschil in perceptie van ons beide. Ik gebruik op dit moment bepaalde generieke code om een query te doen naar een database. Die code is ruim snel genoeg om te doen wat ik wil doen.

Jij zegt dat als die code optimaal is, dat elke query dan optimaal is. Dat is niet waar. Verkeerd gekozen queries kunnen heel langzaam zijn. Daarbij maakt het echt niet uit door wat voor code het uitgevoerd wordt.

Dat jij ervan uitgaat dat jouw applicaties niet te profilen zijn want dat is toch niet nuttig, dan moet je jezelf de vraag stellen: is er ERGENS in jouw applicatie ook maar een seconde 'lag' of traagheid? Moet de gebruiker ook maar ergens wachten? Nee? dan heb je gelijk. Indien ja, dan heb je dus ongelijk en is er een hotspot die wellicht niet nu wellicht wel in de toekomst je gaat opbreken

Ik weet dat er op een aantal plaatsen 'lag' is in mijn applicatie. Ik weet ook waar dat aan ligt.

Dat de gebruiker moet wachten betekent niet dat ik ongelijk heb hoor. Dat kan ook een keuze zijn in het ontwerp.

[ Voor 41% gewijzigd door The End op 30-10-2007 16:03 ]

[EfBe]

The End schreef op dinsdag 30 oktober 2007 @ 15:53:
[...]
Dat is waarschijnlijk een verschil in perceptie van ons beide. Ik gebruik op dit moment bepaalde generieke code om een query te doen naar een database. Die code is ruim snel genoeg om te doen wat ik wil doen.

Jij zegt dat als die code optimaal is, dat elke query dan optimaal is. Dat is niet waar. Verkeerd gekozen queries kunnen heel langzaam zijn. Daarbij maakt het echt niet uit door wat voor code het uitgevoerd wordt.

Dat klopt, maar dat is niet het punt: als jouw query execution code traag is, dan kun je nooit een snelle query krijgen. Heb je snelle query execution code, dan is query alleen traag indien de query an sig traag is, maar dat ligt dan iig NIET aan je execution code.

Als het framework waar je je applicatie mee maakt traag is, krijg je je applicatie nooit snel, het framework zal altijd de vertragende factor zijn, daarom is het wel degelijk van belang bv code te profilen om te zien of wat je hebt gemaakt aan generieke code niet de bottleneck vormt voor de code die de generieke code gebruikt.

[The End]

EfBe schreef op dinsdag 30 oktober 2007 @ 16:54:
Als het framework waar je je applicatie mee maakt traag is, krijg je je applicatie nooit snel, het framework zal altijd de vertragende factor zijn, daarom is het wel degelijk van belang bv code te profilen om te zien of wat je hebt gemaakt aan generieke code niet de bottleneck vormt voor de code die de generieke code gebruikt.

Nogmaals; als die generieke code 1 keer per dag uitgevoerd wordt, dan interesseert het me niet dat het een halve seconde langer duurt. Dan kost het profilen en optimaliseren mij alleen maar tijd.

Ik geloof alleen dat er een misverstand is ontstaan. Ik zeg niet dat profilen nutteloos is oid. Het punt wat ik oorspronkelijk wilde maken, is dat een goed ontwerp (Waarbij er goed nagedacht wordt over eventuele performance issues!) heel belangrijk is.

Het leek hier net alsof de profiler gepositioneerd werd als een ontwerp tool die je pas achteraf toepast.

[.oisyn]

The End schreef op dinsdag 30 oktober 2007 @ 17:13:
Het leek hier net alsof de profiler gepositioneerd werd als een ontwerp tool die je pas achteraf toepast.

Ik denk dat je dan de imho heel erg duidelijke eerste post van EfBe niet goed hebt gelezen, maar soit, kennelijk zijn we het gewoon eens

[roy-t]

EfBe schreef op dinsdag 30 oktober 2007 @ 11:41:
[...]

nprof http://sourceforge.net/projects/nprof/

geen idee of het nog wordt onderhouden, het is wel een aardige profiler. Ikzelf gebruik altijd Ants van Red Gate, omdat de jetbrains profiler soms wat bugt.

De profiler van MS zelf in vs.net 2005 is overigens ook niet slecht, althans voor het opsporen van memory allocations op bepaalde plekken en hoeveel daarvan nog steeds alive is bv.

Thanks dat ga ik voor de lol is door mijn programmatjes gooien kijken wat ie tegen komt (hoewel ik bij mijn hobby programmatjes nou niet iets heb van "omg zo traag!" )

Edit: dat programmatje is hardstikke dood, maar ik ben via de comments uiteindelijk terecht gekomen op ProfileSharp, ook gratis en werkt prima

[ Voor 9% gewijzigd door roy-t op 30-10-2007 17:44 ]