das war eben auch mein gedanke. die größe des zu lesen/schreibenden files, sollte die zugriffszeit ja nur indirekt beeinflussen. zumindest nicht in dem umfang, wie es bei mir mit der aktuellen version des tools der fall ist.
die zugriffszeit soll denke ich angeben, wie lange es dauert, auf ein angefordertes file oder einen angeforderten adressbereich zuzugreifen, nicht wie lange es dauert, diese auch komplett zu lesen bzw zu schreiben. die größe des files bzw des bereichs ist da ja, so mein gedankengang, erst mal sekundär. ich kenne die logik nicht, die im hintergrund diesen zugriff ausführt, aber selbst wenn sie mehr macht, als nur "doof" zugreifen bzw schreiben, so sollte doch unabhängig der größe, der vorgang der logik in abhängigkeit der letztendlichen dateigröße etwa gleich bleiben und somit auch die dafür benötigte zeit.
ist in etwa das gleiche wie die latenz aus der netzwerktechnik, so stelle ich es mir zumidnest vor. "egal" wie groß eine zu übertragende datei ist, die latenz oder paketlaufzeit wird nur indirekt und minimal beeinflusst. beteiligte komponenten müssen unter umständen mehr warteschlangen abarbeiten, sind evtl höher ausgelastet, die komplexität der übertragung steigt, aber im prinzip verändert das die paketlaufzeit nur minimal, denn der weg und die dafür benötigten schritte bleiben in etwa die gleichen.
