Snelste manier om data te benaderen / schrijven

[Armageddon_2k]

Hey mensen,

Ik ben al een tijdje bezig om de snelste oplossing te zoeken om data uit te lezen en weg te schrijven.
Ik heb al een aantal oplossingen geprobeerd (data array's, collections, datasets).

De situatie die ik heb:
een vb.net programma haalt informatie van een PCI kaart, deze kaart bevat (ongeveer) 500 adressen waarvan de waarde snel kand worden uitgelezen.
Op deze data worden verschillende berekeningen losgelaten (varieert elke keer), somme data zal dus meerdere keren worden gelezen en weggeschreven.
Na deze bewerkings cyclus wordt de data weggeschreven naar de PCI kaart.

Deze cyclus herhaalt zich dus elke second:
-Inlezen waarden
-Waarden bewerken
-Wegschrijven waarden

Het inlezen en wegschrijven duurt samen ongeveer 50 ms.

Allen het wegschrijven van de data in een dataset en het inlezen/aanpassen van de data kost veel tijd.
Dit moet vast sneller kunnen, ik kom namelijk in totaal op 700ms, begrijpelijk is dus dat meer data te lang gaat duren.

Ook nog: de data wordt elke cyclus ververst op een datagrid.

Hoe kan ik dit versnellen?, zodra de cyclus namelijk langer dan een seconde duurt lockt mn applicatie.

[Jewest]

Kun je een indicatie geven van je structuren?

Dus hoe zit je collectie in elkaar?
Maak je de collecties elke keer weer opnieuw of refresh je de inhoud?

hoe zwaar zijn je berekeningen? en hoevaak komen ze voor?
500 of zijn het meerdere berekeningen?

[ Voor 24% gewijzigd door Jewest op 15-07-2009 12:22 . Reden: meer vragen. ;) ]

[SKiLLa]

Hoe ververs je de data in het DataGrid ? Doe je stuk-voor-stuk een .Items.Add() ? In dat geval kun je beter Items.AddRange() gebruiken.

Vergeet ook geen .SuspendLayout() en .ResumeLayout() voor en na het vullen te doen, dat kan ook enorm veel tijd schelen. En wat is cyclus doorloop tijd als je het hele DataGrid niet vult ?

En de keuze voor je datastructuren kan inderdaad ook veel schelen, vaak is b.v. een generic-List met daarin een maatwerk-data-class sneller & lichter dan een DataSet; als in: List<MyPCiCardRecord> records ...

Maak je 'MyPciCardRecord' een class met public properties, dan behoudt je nog steeds de (automatische) databinding mogelijkheden (zoals een DataTable heeft); is dat laatste minder belangrijk, dan zou je ook voor een struct kunnen gaan, welke 'nog lichter' is ...

[Woy]

Er is niet één snelste manier om data te benaderen/schrijven. Het is heel erg afhankelijk wat je precies met je data doet. Als je een performance probleem hebt zul je moeten gaan profilen om te kijken waar de bottleneck zit en dan daar wat aan doen.

Als je bijna alleen maar in sequence door de elementen heen loopt ( en er geen elementen tussen hoeft in te voegen ) dan zal een Array je beste optie zijn.

Als je vaak op een key naar een element moet zoeken kun je beter naar iets als heet Dictionary kijken. Als je weer vaak op een value moet zoeken zul je een Binary Tree o.i.d. kunnen gebruiken.

Zonder meer informatie te hebben valt er dus weinig te zeggen.

[Dricus]

Als je applicatie blocked bij een te lange cyclus dan heb je hem niet goed opgezet ben ik bang. Het lijkt er dan namelijk op dat je alles in één thread doet: de main thread van je applicatie. In die main thread worden ook alle GUI events afgehandeld. Het is dus zaak dat er in die thread zo weinig mogelijk gebeurt, want als je main thead blocked, blocked je hele aplicatie omdat er dan geen GUI events meer worden afgehandeld.

Als dit het geval is, dan zou ik als eerste die cyclus in een aparte thread gaan implementeren. Daarnaast zou ik het updaten van je grid los gaan koppelen van de cyclus.

[Armageddon_2k]

Woy schreef op woensdag 15 juli 2009 @ 12:54:
Er is niet één snelste manier om data te benaderen/schrijven.
Zonder meer informatie te hebben valt er dus weinig te zeggen.

Sorry, ik dacht het redelijk te hebben omschreven
Goed here goes:
De data is als volgt opgebouwd:

"Adres" "Naam" "Waarde" "Commentaar"

Naam en commentaar zijn er puur om het duidelijker te maken voor de gebruiker.

Voorbeeld:
Digitale waarden:

Adres = "I 0.0"
Waarde = true / false

Adres = "PIW 500"
Waarde = 0-35676

Ik loop NIET op een vaste volgorde door de adressen.
Behalve bij het inlezen van de waarden.
Bij het bewerken van de data gaat het compleet random, de bewerkingssets worden zelf ingevoerd en zijn dus strek varierend.

Denk bij de bewerkingen aan:
Ingang "I 0.0" is true, dan wordt uitgang "PQW 500" elke seconde opgehoogd met #.

[Woy]

Het lijkt me niet dat je Random items kiest. Je zult selecteren op bepaalde criteria. Als je bijvoorbeeld altijd op Adres selecteerd, dan kun je perfect een Dictionary gebruiken om het juiste element te vinden. Dat is dan alleen een Key lookup. Dat zal veel sneller zijn dan een lijst doorlopen en het element zoeken, want daar zal je gemiddeld n/2 elementen voor moeten doorlopen.

[Armageddon_2k]

Woy schreef op woensdag 15 juli 2009 @ 13:57:
Het lijkt me niet dat je Random items kiest. Je zult selecteren op bepaalde criteria. Als je bijvoorbeeld altijd op Adres selecteerd, dan kun je perfect een Dictionary gebruiken om het juiste element te vinden. Dat is dan alleen een Key lookup. Dat zal veel sneller zijn dan een lijst doorlopen en het element zoeken, want daar zal je gemiddeld n/2 elementen voor moeten doorlopen.

Ik zal eens naar een Dictionary kijken, en wat testjes doen.
Met random bedoel ik dat ik wel zoek op adres, maar welk adres is willekeurig.

[chris]

Dit klinkt echt als een geval van meten is weten. Zoek een goede profile-tool, of doe het zelf. Zorg dat je precies weet welk stukje code lang duurt en bedenk dan hoe je het gaat verbeteren.

[Jewest]

Ik zou je objecten in een array stoppen met je adres als unieke identificatie en daarop sorteren.
Zeker als dit statisch is is dit heel erg snel.

[Woy]

Jewest schreef op woensdag 15 juli 2009 @ 14:41:
Ik zou je objecten in een array stoppen met je adres als unieke identificatie en daarop sorteren.
Zeker als dit statisch is is dit heel erg snel.

Een sorted Array is inderdaad ook een optie, je zou hierop een binary search kunnen doen, echter is een lookup in een Dictonary in de meeste gevallen toch sneller.

[Jewest]

In dit specifiek geval zou het zelf nog kunnen dat je de index gebruikt voor het adres.
Sneller als dat krijg je het denk ik niet.

Just my 2 cents.

[Armageddon_2k]

Jewest schreef op woensdag 15 juli 2009 @ 15:03:
In dit specifiek geval zou het zelf nog kunnen dat je de index gebruikt voor het adres.
Sneller als dat krijg je het denk ik niet.

Just my 2 cents.

Was een goed idee geweest alleen kom ik in de knoei omdat er I, Q, PQW, PIW voor een adres kan staan en hierdoor komen adressen dubbel voor.
Maar goed ik heb de dictionary geprobeerd, even wat testjes mee gedaan, en deze komt in de test setting uit op een goeie 30x sneller dan de huidige setting. Is toch niet onaardig dacht ik

[Woy]

Jewest schreef op woensdag 15 juli 2009 @ 15:03:
In dit specifiek geval zou het zelf nog kunnen dat je de index gebruikt voor het adres.
Sneller als dat krijg je het denk ik niet.

Just my 2 cents.

Een Array accessen met een index is natuurlijk de optimale case, maar of daar een mogenlijkheid voor is is natuurlijk ahankelijk hoe er bepaald word welk element er gepakt moet worden. Maar als je niet de exacte index van een adres weet, blijft een Dictionary IMHO de beste optie. Dat is naast een index lookup alleen een extra hash-calculatie.

[Jewest]

Woy schreef op woensdag 15 juli 2009 @ 15:10:
Een Array accessen met een index is natuurlijk de optimale case, maar of daar een mogenlijkheid voor is is natuurlijk ahankelijk hoe er bepaald word welk element er gepakt moet worden. Maar als je niet de exacte index van een adres weet, blijft een Dictionary IMHO de beste optie. Dat is naast een index lookup alleen een extra hash-calculatie.

Mee eens, maar in het gestelde geval is dit wel mogelijk.

[Woy]

Jewest schreef op woensdag 15 juli 2009 @ 15:14:
[...]


Mee eens, maar in het gestelde geval is dit wel mogelijk.

Dan heb ik misschien informatie gemist, maar ik zie nergens iets waar je direct een index vanaf kunt leiden.

[.oisyn]

Woy schreef op woensdag 15 juli 2009 @ 15:10:
Dat is naast een index lookup alleen een extra hash-calculatie.

En natuurlijk nog minstens één gehele compare van de key zelf, en heel veel als je hash functie teveel collision geeft

Jewest schreef op woensdag 15 juli 2009 @ 15:14:
[...]


Mee eens, maar in het gestelde geval is dit wel mogelijk.

Van wat ik er van kan zien is de index toch echt een string en geen oplopende int, dus ik ben benieuwd hoe je je dat dan had voorgesteld...

[ Voor 34% gewijzigd door .oisyn op 15-07-2009 15:33 ]

[Woy]

.oisyn schreef op woensdag 15 juli 2009 @ 15:30:
[...]
En natuurlijk nog minstens één gehele compare van de key zelf, en heel veel als je hash functie teveel collision geeft

Ok natuurlijk, maar in princiepe is het een lookup in constante tijd ( Mits je er geen collissions zijn, als die te vaak voorkomen heb je meestal gewoon weer een lijst waar je doorheen loopt natuurlijk )

[Jewest]

.oisyn schreef op woensdag 15 juli 2009 @ 15:30:
Van wat ik er van kan zien is de index toch echt een string en geen oplopende int, dus ik ben benieuwd hoe je je dat dan had voorgesteld...

, mijn fout, ik heb niet opzitten letten, iets te veel met low level hardware zitten spelen.

[The Eagle]

Misschien iets heel voor de hand liggend, maar zijn de datatypen vooraf gedefinieerd of werk je met varianten?
Kan me namelijk zomaar voorstellen als je er dwars doorheen gaat en je met varianten werkt, het bepalen van het datatype je zoveel tijd kost

_{Ben geen programmeur en dus al helemaal geen hardwareprogrammeur, maar dit was mijn eerste ingeving}

[Armageddon_2k]

The Eagle schreef op woensdag 15 juli 2009 @ 16:36:
Misschien iets heel voor de hand liggend, maar zijn de datatypen vooraf gedefinieerd of werk je met varianten?
Kan me namelijk zomaar voorstellen als je er dwars doorheen gaat en je met varianten werkt, het bepalen van het datatype je zoveel tijd kost

_{Ben geen programmeur en dus al helemaal geen hardwareprogrammeur, maar dit was mijn eerste ingeving}

De data typen liggen wel al vast, dus deze bepalen hoeft niet.
Adres, Naam, Waarde, Commentaar
STRING, STRING, INT, STRING

Maar ik ga dus nu gebruik maken van een Dictionary, en dan nog even een threadded constructie bedenken om het visualiseren los te koppelen van de data acces/manipulatie.

[Woy]

The Eagle schreef op woensdag 15 juli 2009 @ 16:36:
Misschien iets heel voor de hand liggend, maar zijn de datatypen vooraf gedefinieerd of werk je met varianten?
Kan me namelijk zomaar voorstellen als je er dwars doorheen gaat en je met varianten werkt, het bepalen van het datatype je zoveel tijd kost

_{Ben geen programmeur en dus al helemaal geen hardwareprogrammeur, maar dit was mijn eerste ingeving}

Ik snap niet helemaal hoe je het bedoelt "Met varianten werkt"? Bedoel je misschien dat je het volgende?

code:

var myData = "someData";
//Versus
string myData = "someData";

Als je dat bedoelt zal het bij een goede compiler/interpreter niet veel uitmaken, en in sommige omgevingen zelfs helemaal niks aangezien dan gewoon het type afgeleid word van de assignment at compile-time.

Armageddon_2k schreef op donderdag 16 juli 2009 @ 08:38:
[...]
en dan nog even een threadded constructie bedenken om het visualiseren los te koppelen van de data acces/manipulatie.

Niet zelf een threaded constructie bedenken als je niet heel goed op de hoogte bent van de materie, anders loop je straks tegen erg vreemde fouten op . Je moet gewoon een uitgewerkte constructie pakken. In .NET kun je bijvoorbeeld het best gebruik maken van de BackgroundWorker ( Als je het alleen doet om je GUI responsive te houden ), andere omgevingen zullen ook best-practices hebben om het te doen.

[.oisyn]

Woy schreef op donderdag 16 juli 2009 @ 08:47:
en in sommige omgevingen zelfs helemaal niks aangezien dan gewoon het type afgeleid word van de assignment at compile-time.

Is dat niet altijd zo? Moet je niet 'dynamic' gebruiken als je echt runtime typing wilt hebben?
Overigens heeft ie het denk ik over het VB type variant, wat een beetje gelijk staat aan C#'s dynamic (maar altijd al bestaan heeft)

[Woy]

.oisyn schreef op donderdag 16 juli 2009 @ 09:40:
[...]

Is dat niet altijd zo? Moet je niet 'dynamic' gebruiken als je echt runtime typing wilt hebben?
Overigens heeft ie het denk ik over het VB type variant, wat een beetje gelijk staat aan C#'s dynamic (maar altijd al bestaan heeft)

Als er runtime nog bepaald moet worden wat voor type er op een adres staat zal dat lijkt mij een klein beetje overhead introduceren. Een dynamic type zoals in C# zal het inderdaad niks uithalen, aangezien het type gewoon bekend is, het is dan immers alleen wat syntactic sugar voor de luie programmeur

edit:
O wacht je hebt het over echt dynamic typing zoals in .NET 4.0 geintroduceerd word. Ik dacht even dat je het over het var keyword had. Dat is immers alleen syntactic sugar. Echt dynamic typing zal altijd wel wat overhead mee-brengen lijkt mij. Maar ook die overhead lijkt mij niet het eerste punt waar je gaat kijken als je performance problemen hebt.

[ Voor 21% gewijzigd door Woy op 16-07-2009 10:15 ]

[.oisyn]

Mijn hele punt was dat je zei "in sommige gevallen". Maar 'var' doet helemaal niets wat je niet met statische typering kan doen. Het is dan ook statische typering, maar dan aan de hand van het resultaat van de expressie (die @ compiletime natuurlijk al bekend is). Hoe goed je compiler is doet er ook niet toe - de code is exact hetzelfde.

Tenzij je het over 'dynamic' hebt, zoals geintroduceerd in C# 4, maar dat had je dus blijkbaar niet . Maar een VB Variant is dus met C#'s dynamic vergelijkbaar.

[ Voor 32% gewijzigd door .oisyn op 16-07-2009 10:24 ]

[Woy]

.oisyn schreef op donderdag 16 juli 2009 @ 10:21:
Mijn hele punt was dat je zei "in sommige gevallen". Maar 'var' doet helemaal niets wat je niet met statische typering kan doen. Het is dan ook statische typering, maar dan aan de hand van het resultaat van de expressie (die @ compiletime natuurlijk al bekend is).

Ja dat zeg ik ook

Dat is immers alleen syntactic sugar.

Hoe goed je compiler is doet er ook niet toe - de code is exact hetzelfde.

Tenzij je het over 'dynamic' hebt, zoals geintroduceerd in C# 4, maar dat had je dus blijkbaar niet

Dat stuk over de compiler/interpreter ging er over hoe er met dynamic typing om gegaan zou worden, en dan doelde ik wel op een vorm zoals dynamic in C# 4.0. Ik had in mijn code sample express geen C# neergezet

[ Voor 3% gewijzigd door Woy op 16-07-2009 10:26 ]

[.oisyn]

Woy schreef op donderdag 16 juli 2009 @ 10:24:
[...]

Ja dat zeg ik ook

Nu wel ja

Ik weet niet hoe slim de VB compiler omgaat met variants. De feature zat voorheen nog niet in .Net dus op de VM kun je sowieso niet rekenen.

[ Voor 88% gewijzigd door .oisyn op 16-07-2009 10:34 ]