Work with RAM. 1.7.0.243

[Max N]

When you run the program takes 195 MB of RAM.
Opened in the program 10 cr2 files. Closed all tabs.
The program takes 3.6 gigabytes of memory.
This is normal?

[Rick G]

Sounds like a leak somewhere. I am getting that with smaller JPG files when I loaded 28. The memory load when up from 200 l when freshly started to almost 600 l. When I closed them all out it dripped to th 580 k and no further

[walt.farrell]

I'm not sure if that's normal or not. However,

1. I started Photo 1.7.0.243 and it used 322MB of storage.
2. I then opened 10 JPEG files (2MB to 4MB each) and that went up to 1172MB.
3. I closed them and it only dropped to 1140MB memory usage, which seems wrong.
4. But, I reopened them and it only went up to 1225MB.

So, it appears that at step 3 it did not release much memory, but it reused it at step 4. In other words, it did not leak a large amount of memory. But this did not involve any developing of raw files.

So,

1. I restarted Photo 1.7.0.243 (316MB), and
2. Opened 10 NEF files (around 18MB each). Photo was now using 4460MB.
3. After clicking Develop on each, Photo was using 7099MB.
4. Immediately after closing each of them, Photo was using 7009MB
5. I then opened 10 different NEF files (again, 18MB each). Photo's memory usage was 6253MB. so, it reused a bunch of the memory it had retained, as it had gone down from 7009MB.
6. I then started developing, planning to repeat steps 3 and 4. Unfortunately Photo crashed after the 3rd NEF file was developed.

In any case, it does not seem to be a large growing memory leak; I think that Photo is simply acquiring memory and rather than immediately freeing it when it's not needed, is keeping it around for future use.

 

[v_kyr]

Well I think they probably do use .Net managed code and thus GC for memory handling.

If the .Net GC one operates similar to the Java GC here, then the GC allocates needed heap memory for the app here, the size of memory depending on run processes/tasks etc.

[Image:  allocated vs used memory tracking in a JVM with periodically forced GC]

From that allocated memory a certain amount of memory is used, as far as objects/data are used and not marked to be freed by an automatic or forced performed GC freeing. So the used memory will vary here inside the app and change often, but the allocated heap memory will not shrink that fast in contrast here.

One often have to finetune things here programmatically, even when using GC for memory handling in programming. - Since only unused/unreferenced objects are freed at all by the GC, so if there is still somewhere a dangling reference to an object, even it's no longer used in the app, it's not freed up. Also if there are possible memory leaks, circular object references and so on in an app, than portions of the allocated memory will not shrink here even over time, instead the memory usage will grow and accumulate then.

[Mark Ingram]

For ref, we only use .NET for the UI, so the memory usage is unrelated to garbage collection.

Now, for the interesting part, yes, the memory usage will appear much higher in this build, and you will not be able to open a file, then close a file, and compare the amount of memory in use. We need to make sure the amount of memory doesn't keep increasing through the lifetime of the application, hopefully it should steady out at a certain level (which will depend on what you've got set in performance preferences).

[v_kyr]

15 minutes ago, Mark Ingram said:

For ref, we only use .NET for the UI, so the memory usage is unrelated to garbage collection.

How is that unrelated if the whole app UI uses .Net managed code then and you load up let's say 10 NEF files in it for show up of their images, perform scaling up/down images in the UI, redrawing and renderding to the UI display, aka all is initiated and shown up by the UI widgets stuff?

[Max N]

1 hour ago, Mark Ingram said:

For ref, we only use .NET for the UI, so the memory usage is unrelated to garbage collection.

Now, for the interesting part, yes, the memory usage will appear much higher in this build, and you will not be able to open a file, then close a file, and compare the amount of memory in use. We need to make sure the amount of memory doesn't keep increasing through the lifetime of the application, hopefully it should steady out at a certain level (which will depend on what you've got set in performance preferences).

If the AP is running during the working day, and I open 100-200 images per day - will this affect the performance of the AP or not? Do I need to restart the program each time or will the used memory size be used as efficiently as if I had just opened the program?

[Patrick Connor]

UI is being used in a more technical sense than you are implying. The screen drawing code does not fall under the definition of user interface. We mean the toolbars and studios, nothing else, particularly not the rendering of the images to the screen or particularly the processing of the filters where most of the memory is used. The user interface cares not which document is open (or even if one has been, let alone 10 big images). 

[v_kyr]

Then the canvas, it's contents/preview/updating etc. have to be decoupled from .Net parts here and you just use certain of the .Net GUI elements (panels and widgets) around that for the UI show up. - So to say the UI is a sort of a composite mixed (two tier implementation), beside an overall frontend & backend architecture?

[Mark Ingram]

12 hours ago, v_kyr said:

How is that unrelated if the whole app UI uses .Net managed code then and you load up let's say 10 NEF files in it for show up of their images, perform scaling up/down images in the UI, redrawing and renderding to the UI display, aka all is initiated and shown up by the UI widgets stuff?

Because the code that loads 10 NEF files is not managed.

[Mark Ingram]

11 hours ago, Max N said:

If the AP is running during the working day, and I open 100-200 images per day - will this affect the performance of the AP or not? Do I need to restart the program each time or will the used memory size be used as efficiently as if I had just opened the program?

No, there is no need to restart. Let me know if you have any problems with performance, or needing to restart, etc. 

[Mark Ingram]

On 2/16/2019 at 7:55 PM, Mark Ingram said:

Now, for the interesting part, yes, the memory usage will appear much higher in this build, and you will not be able to open a file, then close a file, and compare the amount of memory in use. We need to make sure the amount of memory doesn't keep increasing through the lifetime of the application, hopefully it should steady out at a certain level (which will depend on what you've got set in performance preferences).

I've investigated this further, and we are actually using more memory than expected (though my statement about comparing the before and after levels of memory still stands). You should hopefully see an improvement in this for the next build. Thanks @Max N.

[juliep]

Thanks Mark,

I have found it extremely memory hungry to the point of it crashing my computer a lot as well as getting stuck in a loop.

Here's a screenshot eg:

IT often takes a considerable time just to 'develop' an image & as for HDR merging - maybe half an hour, during which time the computer is unusable, often crashing as well.

I was using RAW files. Am I better running an HDR merge with JPGs?

I am running Windows 7 with 8GB RAM.

Even when I'm not using it, it uses an awful lot of memory.

I am wanting to update my computer anyway but the memory issues are way worse than the production version.

When  1.7 is released for real, will these issues be resolved?

Thanks,

Julie.

[Mark Ingram]

Are you using 251 right now @juliep? 5GB of RAM use isn't really a lot, depending on what you have done at that point. Do you have an SSD or HDD?

[juliep]

Hi Mark,

You mean the release number? Am using 1.7.243. If there's a 1.7.251 around, maybe I should try that then? It was more the fact that AP was using all the RAM I had! My next laptop will be 16G?B I should think. The laptop is also 6 years old & Windows 7 so not in its prime!

I'm actually using an external drive through USB3.

Julie :-)

[Blende21]

From my experience with AP and Lightroom 6, if you load pictures with 25-40 MB size (preferrably RAW), anything below 16 MB will get unstable at one point or the other. I‘ve retrofitted my Win10 to 16GB some time ago. I found that with 8 GB plus a SSD before, the programs struggled and memory-managed muddled through for a while, but always failed earlier or later. RAM was permanently exchanged with the SSD, which was no fun as well.

With 16 GB, RAM usage goes up to about 12GB fast, but then tends to stay in that range. I think that 16GB should be the minimum for serious work on digital fotos. 

Afterthought: I stuck with Win 7 for quite some time, but am happy to have made the switch to Win 10. The OS is superior to an aged (and often clogged) Win 7 by all means.

[juliep]

Thanks Blende. I hope to have a new laptop soon & will be Windows 10. I'll make sure it's fit for use too!

[Andrew Windsor]

Since the 1.9 release my Affinity Photo is hanging with almost every element used, its driving me barmey. I have even set the priority to high and it still struggle and hangs my pc. Please can you release a memory fix, thank you. The screen shot with 5 layers of work and the Task manager in is before memory priority being edited and the screenshot of Task manager on its own is with Priority set to high.

 

 

[Move Along People]

-