FieldGroup fyldes med Fields efter følgende recept, med FieldName som key.
FieldGroup fg = new FieldGroup(); string aName; object aValue; fg(aName) = new Field(myName, myValue);
Jeg kunne godt tænke mig nogle bud på den mest effektive metode til at beregne en unik hashcode for sådan et FieldGroup objekt baseret på dennes Field objekter. Se venligst gennem fingre med den meget eksemplificerede kode :)
Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
public int GetHashCode() { int res = 0; string key; Field fld; foreach (int key in this.Keys) { fld = this(key); res + = fld.GetHashCode(); } return res; }
Det er ikke helt nemt at lave god ehash funktioner, men du kan godt regne med at Microsoft har gjordt et godt arbejde, så hvis din kode bygger oven på deres, så går du ikke helt galt.
En hashtable kan sagtens håndtere forskellige keys med samme hash værdi.
Det er en nødvendighed. Tænk på hvor mange forskellige string værdier der er og hvor mange forskellige int værdier der findes. Logisk set må mange string værdier hashes til samme int værdi.
Pointen er at hvis rigtigt mange værdier hashes til samme hash code så går det ud over performance af Hashtable.
Men et tilfældigt match her og der gør ikke noget.
Så er der noget helt generelt jeg misforstår her. En hashtable laver så vidt jeg har erfaret sin sammenligning af om to objekter er ens ud fra en IHashCodeProvider.
Og kommer to forskellige objekter frem til samme HashVærdi vil en af dem jo ikke kunne være i HashTablen ???
Den er nu implementeret som følger : public override bool Equals(object obj) { Field toCompare = ((Field)obj); return (this._fieldName.Equals(toCompare.FieldName)) & (this._fieldValue.Equals(toCompare.FieldValue)); }
En primitiv hash tabel kan laves som med 3 felter key,value,next.
Så allokerer du 200 elementer i alle 3 arrays.
Når du indsætter så tager du modulus 10 af hash code af key. Og bruger det som index i arraysene. Hvis pladsen er tom indsætter du. Hvis pladsen er i brug finder du det første frie plads med index >= 10 og lader next i det først fundne pege på det index.
Jeg har lige lavet et par performance målinger mellem at bruge streng metoden og din int metode hvor jeg godt nok dividerer med 2 for ikke at få overflow resultatet er ret overbevisende : (Jeg laver en distinct udvælgelse af records i en DataTable med 102.368 rows - Burde være rimelig worst case)
STRENGE
End DB SELECT: 8,55306506817516 sec. Start DISTINCT VIEW End DISTINCT VIEW: 2,5897787560622 sec. Total count: 102368 Distinct count: 35
INT / 2
End DB SELECT: 8,50959844079225 sec. Start DISTINCT VIEW End DISTINCT VIEW: 1,3752819430457 sec. Total count: 102368 Distinct count: 35
Så der er altså med disse datamængder næsten en faktor 2 til forskel
Har faktisk fået det optimeret endnu mere da du lærte mig at det der med det unikke ikke er 100% vitigt for hashcodes, bare equels styrer det. Så nu laver jeg kun hashcode på value, det barberede lidt mere af tiden, dog ikke så meget
Men vær opmærksom på at hvis du har mange Fields med samme value men forskellig name, så vil det give dårlige lookup tider fordi de får samme hash code.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.