AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Effektivität von Records und Objekten

Ein Thema von Gargamel · begonnen am 28. Dez 2011 · letzter Beitrag vom 29. Dez 2011
Antwort Antwort
Seite 2 von 2     12
Iwo Asnet

Registriert seit: 11. Jun 2011
313 Beiträge
 
#11

AW: Effektivität von Records und Objekten

  Alt 29. Dez 2011, 13:29
Also bei dem Verwaltungskram verwende OOP. Die paar Nanosekunden, die man vielleicht (wenn überhaupt) einspart, lohnen nicht den Mehraufwand.

Programmierer und strukturiere sauber, dann wird es auch schnell (genug). Wenn Du nicht völlig bekloppt programmiert hast, dann kannst Du zum Schluss noch an den kernigen Stellen etwas rausholen.

Nach meinen bescheidenen Kenntnissen produziert eine Klasse beim Instantiieren und bei virtuellen Methodenaufrufen etwas Overhead, aber ansonsten verhält es sich (vom Zeitverhalten her) wie ein Zeiger auf ein Record.

Wenn du mit 'Handles' arbeiten willst, dann würde ich eine Dictionary nehmen. Wenn ein Objekt eingetragen wird, erzeugst Du eine ID und das ist das Handle. Das ist sicherer als ein Index oder eine als 'Handle' gecastete Adresse.

Wenn du auf ein Objekt zugreifen willst, suchst Du in der Dictionary nach dem Handle, das geht sauschnell und produziert nur ein paar CPU-Zyklen overhead. Wird es nicht gefunden, kannst Du sehr sauber reagieren. Bei als Handle verkleideten Indizes oder Instanzzeigern kann man schnell richtig viel versaubeuteln ohne zu merken, was Sache ist.

Was das Exceptionhandling anbelangt ist nur das Auftreten einer Exception selbst performancetechnisch zu vermeiden. Das TRY an sich ist eigentlich nicht spürbar.

Also solltest Du mit TRY-EXCEPT arbeiten und ansonsten Exceptions vermeiden. Leider geht das oft zu Lasten der Lesbarkeit.

Ich würde mich übrigens an deiner Stelle hüten, nur auf Performance zu gehen, denn Lesbarkeit und vor allen Dingen "Robustheit" geht irgendwie vor, finde ich.
  Mit Zitat antworten Zitat
Gargamel

Registriert seit: 19. Mär 2007
171 Beiträge
 
#12

AW: Effektivität von Records und Objekten

  Alt 29. Dez 2011, 14:04
Zitat:
Wenn du mit 'Handles' arbeiten willst, dann würde ich eine Dictionary nehmen. Wenn ein Objekt eingetragen wird, erzeugst Du eine ID und das ist das Handle. Das ist sicherer als ein Index oder eine als 'Handle' gecastete Adresse.

Wenn du auf ein Objekt zugreifen willst, suchst Du in der Dictionary nach dem Handle, das geht sauschnell und produziert nur ein paar CPU-Zyklen overhead. Wird es nicht gefunden, kannst Du sehr sauber reagieren. Bei als Handle verkleideten Indizes oder Instanzzeigern kann man schnell richtig viel versaubeuteln ohne zu merken, was Sache ist.
Das habe ich leider garnicht verstanden.

Edit: Nur um Missverständnissen vorzubeugen. Die Objekt-ID, die durch AI_registerObject(...) und AI_removeObject(...) übergeben wird, ist eine von der 3D-Engine zugewiesene ID. Daran kann ich nichts ändern. Diese ID hat nichts mit dem Index in der KI-Liste zu tun.

Geändert von Gargamel (29. Dez 2011 um 14:08 Uhr)
  Mit Zitat antworten Zitat
Iwo Asnet

Registriert seit: 11. Jun 2011
313 Beiträge
 
#13

AW: Effektivität von Records und Objekten

  Alt 29. Dez 2011, 15:37
Alles klar, in den vorigen Posts kamen Ideen auf, Referenzen als Handles zu definieren. Wenn die 3D-Engines bzw. der Anwender der "KI" die IDs selbst vergibt, umso besser. Dann sind es für dich nur anonyme Identifikatoren. Hauptsache eindeutig.

Hier ist es mit Sicherheit am schnellsten, mit einer Dictionary zu arbeiten. Diese verwaltet in einer Art Liste die Objekte und rückt sie (sehr schnell) unter Angabe der ID wieder heraus.
  Mit Zitat antworten Zitat
Gargamel

Registriert seit: 19. Mär 2007
171 Beiträge
 
#14

AW: Effektivität von Records und Objekten

  Alt 29. Dez 2011, 16:12
Was ich bis jetzt bei all den Posts herauslesen konnte, nehmen sich Records und ein objektorientierter Ansatz nicht viel. Weder bezüglich Performance, noch Speicherverbrauch. Wobei OOP wegen Übersichtlichkeit und der schnelleren Erweiterbarkeit vorzuziehen ist.

@Iwo Asnet:

Mit Dictionary sind TList bzw. TObjectList gemeint? Wenn ja, wäre deren Vorteil einzig der, daß ich kein zweites dyn. Array brauche, um das erste dyn. Array nicht größer als nötig werden zu lassen. (wegen Löschung einzelner Elemente)

Zitat:
Diese verwaltet in einer Art Liste die Objekte und rückt sie (sehr schnell) unter Angabe der ID wieder heraus.
Aber was genau ist mit ...unter Angabe der ID... gemeint?
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#15

AW: Effektivität von Records und Objekten

  Alt 29. Dez 2011, 18:52
Nee, eine Dictionary ist eine 'Liste' (eigentlich egal, was es genau ist), wo Du unter Angabe eines Schlüssels Daten ablegen kannst. So z.B.

Delphi-Quellcode:
MyDictionary.Add(ID, Data);
...
// später
...
MyData := MyDictionary[ID];
//
  Mit Zitat antworten Zitat
Gargamel

Registriert seit: 19. Mär 2007
171 Beiträge
 
#16

AW: Effektivität von Records und Objekten

  Alt 29. Dez 2011, 20:13
Ich kann die Klasse TDictionary bei mir nicht verwenden. (ich nutze Delphi Turbo Explorer)
Die Unit Contnrs beinhaltet die Klasse leider nicht.
  Mit Zitat antworten Zitat
Klaus01

Registriert seit: 30. Nov 2005
Ort: München
5.753 Beiträge
 
Delphi 10.4 Sydney
 
#17

AW: Effektivität von Records und Objekten

  Alt 29. Dez 2011, 20:23
.. vielleicht könntest Du dir mal anstelle dessen die THashmap anschauen.

Grüße
Klaus
Klaus
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 07:46 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz