Administrateur

  • Profile picture of Karim
  • Profile picture of Jean

OpenMusic

Groupe Public active 16 hours et 14 minutes ago

User group for OpenMusic and computer-aided composition. Visit the Forum for discussions.

Memory Allocation?

Auteur 3 Utilisateurs souscrits |
Profile photo of lt72music
lt72music

Hello! Any simple tips on what I might change to avoid errors like these? They happen when I’m far enough into an OM session and I’ve already evaluated some of my patches that have “repeat-n” calls with either a high enough “n” or a sufficient number of evaluations. Even when I wait long enough for the process to terminate, there still seems to be something building up in memory. In the case of this screenshot, each evaluation is generating 5 measures of music and selecting 4 images randomly from a directory list of about 20,000 photos. If I set the “n” of the repeat-n at say 20, I can evaluate successfully a few times, but I’ll eventually get the allocation error, seemingly no matter how long I wait. I have to close the OM session to get back to normal. I can attach a patch if it helps. Thanks!

Attachments:
  1. memory

    memory.png

Janvier 21, 2019 à 23:21 #28937
Profile photo of Jean
Jean

Hi — I have seen this problem before, but generally when OM explicitely allocates external memory (typically for audio management) and doesn’t deallocate it correctly.

As you probably know, memory management in Lisp (and OM) is done through automatic garbage collection, which make it easy to program (you don’t have to allocate/deallocate memory), but sometimes harder to control. Memory should be released as soon as the data is not reachable anymore (that is, when no other object refers to it) — you can trigger a garbage collection manually in LispWorks by calling (GC-ALL). Ensuring that your data will be collected and freed is not always straightforward, and several reason can stand on the way: circular dependencies, side effects, etc.

Would you mind sharing your patch so I can see if there’s anything specific in there ?
(If possible, the most simplified possible version of it that would allow me to reproduce the problem.)

Jean

Janvier 23, 2019 à 10:17 #28941
Profile photo of lt72music
lt72music

Thanks Jean. Great info. I’m seeing improvement already by rewriting some of my functions, replacing recursives with “dotimes” and am going to continue to do so, and will attach a patch when I have things more streamlined. Again, much appreciated!
best, Leonard

  • Cette réponse a été modifiée 3 weeks et 6 jours ago par Profile photo of lt72music lt72music.
Janvier 23, 2019 à 21:33 #28943
Profile photo of anders
anders

Hi Leonard.

Checked ‘slots’-box vs. new instances?

I have no idea whether this relates to the troubles you’re seeing, but one mistake i’ve seen many people do is unneccesary duplicating of data inside sub-patches. E.g. to access some data from an outside chord-seq inside a sub-patch, a new chord-seq is added to the input box of the sub-patch. This is ok in simple situations, but when patches and systems grow more complex, this approach soon starts pushing memory usage.

Instead, inside the sub-patch, take care to use ‘slots’-versions of the structure passed to the input, and access whatever data from the outside you’re interested in. Check attached example.

-anders

Attachments:
  1. Skjermdump-fra-2019-01-23-23-26-41

    Skjermdump-fra-2019-01-23-23-26-41.png

Janvier 23, 2019 à 23:42 #28945
Profile photo of anders
anders

unneccesary duplicating of data inside sub-patches

And of course, this is even more important inside loops or recursive programs…

Janvier 23, 2019 à 23:58 #28948
Profile photo of lt72music
lt72music

Thanks, Anders! I’ve never dealt with the slot vs instance distinction in patches, and I’m looking forward to playing with it. Much appreciated!
Best,
Leonard

Janvier 24, 2019 à 00:02 #28949

Vous devez être connecté pour répondre à ce sujet.

Log in now