EnsureRange vs. Min( 0, Max( 1, Value )) unter CrossPlatform

[Rollo62]

Hallo zusammen,

ich möchte eine Zahl in einem Bereich begrenzen und dafür gibt es ja EnsureRange:

Delphi-Quellcode:

function EnsureRange( const AValue, AMin, AMax : Single   ) : Single;

function EnsureRange(const AValue, AMin, AMax: Single): Single;
begin
  assert(AMin <= AMax);
  if AValue < AMin then
    Result := AMin
  else if AValue > AMax then
    Result := AMax
  else
    Result := AValue;
end;

Die ist aber nicht

Delphi-Quellcode:

inline

und hat noch den

Delphi-Quellcode:

assert

Wobei die Funktionen Min/Max

Delphi-Quellcode:

inline

sind und auf den

Delphi-Quellcode:

assert

verzichten.

Delphi-Quellcode:

function Min(const A, B: Single): Single; overload; inline;

function Min(const A, B: Single): Single;
begin
  if A < B then
    Result := A
  else
    Result := B;
end;

Ich frage mich welche Version performanter ist, wenn ich auf einen

Delphi-Quellcode:

assert

verzichten kann und das auch auf allen Platformen benutzen möchte:

Delphi-Quellcode:

    Result := EnsureRange( 0.0, 1.0, AValue );
    // oder
    Result := Min( 0.0, Max( 1.0, AValue ) );

Es sollte eigentlich EnsureRange sein, ich bin mir da aber nicht sicher wie und ob die verschiedenen Compiler das optimieren.
Vielleicht hat da jemand einen Hinweis für mich ?

[freimatz]

Eine inline ist generell performanter. Aber spielt das wirklich eine Rolle?
https://clean-code-developer.de/die-...e_Optimization
Wenn dann würde ich eine inline Variante von EnsureRange machen.

[Rollo62]

Zitat:

Zitat von freimatz (Beitrag 1511126)

Eine inline ist generell performanter. Aber spielt das wirklich eine Rolle?

Ich würde das in dem Fall jetzt nicht nicht "Überoptimierung" nenne, denn wenn EnsureRange sehr oft und an vielen Stellen aufgerufen wird ist es doch der erste Kandidat für ein Profiling Problem.
Ich frage ja nur ob vielleicht shcon jemand Beides verglichen hat.

[freimatz]

Ich vermute eher Nein. EnsureRange habe ich auch erst durch Dich kennengelernt.
Was meinst Du mit Profiling Problem? Ich habe eines, weil ich mit dem Profiler AQTime nicht umgehen kann :wink:

Um was geht es Dir? Was ist der Hintergrund? Ist eine konkrete Funktion einem Anwender zu langsam? Geht es um eine akademische Betrachtung der Geschwindigkeit der Varianten?

[Rollo62]

Ich möchte einen wahlfreien Zugriff von aussen möglichst absichern in dem der Zugriff auf das Min und Max limitiert wird.
Ansonsten müsste ich jeden Zugriff von aussen der Klasse absichern, was ich nicht möchte.
Der Zugriff kann von mehreren Stellen erfolgen und in dem Fall das Array kann schon ein paar Werte enthalten.
Normalerweise würde ich solche Abfragen vor einer Scheife machen und dann "unsafe" zugreifen, aber hier können verschiedene Stellen auch teilweise über das Array erfolgen.
Deshalb suche ich nach der Besten Clamping Methode um das "safe" zu machen.
Die Performance ist noch moderat, aber es geht um ImageProcessing und da wäre ich gerne auf der sicheren Seite.
Profiling habe ich hier nicht eingerichtet, auch weil es um CrossPlatform geht.
Wäre schön wenn es da was einfaches gäbe, hab's aber bislang nicht gefunden.

[freimatz]

Einfaches Profiling? :bounce1: Habe ich auch noch nicht gefunden.

Das was Du schreibst trifft nicht ganz meine Frage. Aber ImageProcessing sagt mir was.
Also mein Vorschlag: Mach doch eine eigene "EnsureRange". Nimm die von oben, mach den "assert" weg und den "inline" dazu. Fertig.

[Stevie]

Die RTL wird ohne Assertions kompiliert, das siehst du übrigens, wenn du mal in EnsureRange reindebuggst.

Übrigens, du hast oben

Delphi-Quellcode:

EnsureRange( 0.0, 1.0, AValue );

geschrieben, aber ich gehe davon aus, dass du

Delphi-Quellcode:

EnsureRange( AValue, 0.0, 1.0 );

meintest

Zitat:

Zitat von Rollo62 (Beitrag 1511128)

wenn EnsureRange sehr oft und an vielen Stellen aufgerufen wird ist es doch der erste Kandidat für ein Profiling Problem.

Kaum, außer du rufst EnsureRange laufend in Schleifen auf.

Ansonsten Regel Nummer 1 - Anwendung durch nen Profiler jagen (und damit meine ich einen SamplingProfiler - und keinen Instrumentation Profiler wie AQTime), um eine grobe Idee zu bekommen, was wirklich die Zeit verbraucht.

[himitsu]

Wer viel Misst misst Mist.

Hatte es schon, dass in einer Schleife ganz viel Zeit angezeigt wurde, aber die Zeit kam vom AQTime (mit Profiler war es auch insgesamt viel langsamer)
Nach dem Umbau fiel dann auf, dass Dort die gesamte Schleife eigentlich garnicht so langsam war, auch wenn in der Schleife etwas einige Millionen Male gemacht wurde.


Es ist schon eine Kunst die Resultate auch richtig auszuwerten.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1511256)

Es ist schon eine Kunst die Resultate auch richtig auszuwerten.

Nein, die "Kunst" ist es, zu wissen, wie AQTime bzw ein sogenannter Instrumentation Profiler funktioniert :roll:

Bei absolut fein granularem Profiling ist Instrumentierung einfach nicht zu gebrauchen, da der Overhead bzw die Laufzeitveränderung durch diese das Ergebnis verfälscht.

[Rollo62]

Ok, ich werde im Moment bei EnsureRange bleiben, ist nicht so kritisch.
Der Hinweis zu dem Assertions ist sehr interessant, werde ich mir merken :thumb:

Zitat:

Zitat von Stevie (Beitrag 1511245)

Ansonsten Regel Nummer 1 - Anwendung durch nen Profiler jagen (und damit meine ich einen SamplingProfiler - und keinen Instrumentation Profiler wie AQTime), um eine grobe Idee zu bekommen, was wirklich die Zeit verbraucht.

Das würde ich auch gerne machen, aber die gibt es ja nur für Windows(32).
Mir geht es auch darum ob es sich auf allen Plattformen dann ähnlich verhält, weil das ja ganz unterschiedliche Compiler und Systeme sind.
Soweit ich weiss gibt es keinen CrossPlatform-Profiler, oder etwa doch ?