Vielen Dank fuer ihre Hilfe, das Problem wurde geloest: man muss statt benutzen.
Also das war wirklich kein Speicherleck, sondern nur Missbrauch wegen dem Datentyp.

__blackjack__ hat geschrieben: Freitag 30. Oktober 2020, 13:51 Mal eine ganz dumme Frage: Wie viele Bytes belegt denn *ein* Element vom `resize()`\ten `frame`? Bei dem `zeros()`-`frame` sind es 8 Bytes pro Element.

Du hast Recht, getsizeof() zeigt, dass die Groessen von Objekten sich unterscheiden. np.zeros() ist ~10 Mal groesser als cv2.resize().

Das ist die Version, die funktinoiert: https://www.kaggle.com/kuto0633/gfootba ... nvironment Ihr wisst, welche Zeile zu ersetzen ist)

Ich fuehre das in Google Colab (wenn es eine Rolle spielen kann)

Stimmt, ich habe meine Frage nicht genug anschaulich formatiert. Ich korrigiere das:

# erste Version (mit dem Speicherleck)
def observation(self, frame):
data = copy(frame)
frame = np.zeros(self.observation_space.low.shape)
return frame.reshape(self.observation_space.low.shape)


# zweite ...

Ohne dass wir beide Programme komplett kennen, ohne zu wissen, welche Dimensionen die Arrays haben, kann man dazu nichts sagen.


Beide Programme unterscheiden sich voneinander um 1 Zeile, die Dimensionen in beiden Faellen sind gleich -> ein Programm brauch 3 GB, zweites Programm brauch 12 GB ...

@__blackjack__ Im ersten Fall braucht das Program mehr als 12 GB, im zweiten - weniger als 3 GB, deswegen glaube ich, dass es am Speicherleck liegt. Code steht wirklich in dem Program. Warum ich diese komische Sachen schreibe? Weil ich den Unterschied zwischen diesen zwei Versionen moeglichst klein ...

Hi,

in meinem Projekt benutze ich numpy und cv2 und habe ein volgendes Problem mit dem Speicherplatz:
def observation(self, frame):
data = copy(frame)
frame = np.zeros(self.observation_space.low.shape)
return frame.reshape(self.observation_space.low.shape)
diese Funktion fuehrt zu dem ...