Jump to content
Max N

Work with RAM. 1.7.0.243

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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


Affinity Designer 1.7.0.367 & beta 1.7.0.390 Affinity Photo 1.7.0.367 beta  1.7.0.390 Affinity Publisher 1.7.0.399

Windows 10 Pro 64-bit 1709

CPU Intel Core i7 4770 @ 3.40GHz Haswell 22nm Technology

RAM 32.0 GB Dual-Channel DDR3 @ 798 MHz (11-11-11-28)

Motherboard Gigabyte Technology Co. Ltd. B85M-D3H (SOCKET 0)

Graphics Intel HD Graphics 4600 (Gigabyte)

yoda.png

Share this post


Link to post
Share on other sites

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.

 


-- Walt

Windows 10 Home, version 1903 (18362.145), 16GB memory, Intel Core i7-6700K @ 4.00Gz, GeForce GTX 970
Affinity Photo 1.7.1.404 and 1.7.1.404 Beta   / Affinity Designer 1.7.1.404 and 1.7.1.404 Beta  / Affinity Publisher 1.7.1.399 Beta

Share this post


Link to post
Share on other sites

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.

memmon.gif.1c499586ada1bdbd2f576f8231e916a2.gif

[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.


☛ Affinity Designer 1.7.0 ◆ Affinity Photo 1.7.0 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites
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?


☛ Affinity Designer 1.7.0 ◆ Affinity Photo 1.7.0 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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). 


Patrick Connor

Serif (Europe) Ltd.

Share this post


Link to post
Share on other sites

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?


☛ Affinity Designer 1.7.0 ◆ Affinity Photo 1.7.0 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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:

image.png.4c78f25cd5f2d54db7ec4276a041fcd5.png

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.

Share this post


Link to post
Share on other sites

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 :-)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×