Size file brush and styles

[Sergo]

Hi
Why, if you delete for example brush categories, or styles, raster_brushes file.procol or object styles.procol
increases,
Can someone tell me why?

[R C-R]

What OS (Mac or Windows) are you using? Have you tried this with the Affinity app open or have you quit it first?

[Sergo]

Windows 10 x64 on windows 7 too
Many times I have been in different ways
After removing the brushes or styles, the raster_brushes.propcol file does not even get much bigger,
I reinstalled the applications, and the last update installed and sbarsyval settings, still do not understand why the file becomes only more after removing

 

[Lee D]

Th

On 08/03/2018 at 9:06 AM, Sergo said:

Hi
Why, if you delete for example brush categories, or styles, raster_brushes file.procol or object styles.procol
increases,
Can someone tell me why?

There does seem to be something strange going on with those files when deleting or adding brush categories. I'll do some more testing and feedback to the developers.

[Sergo]

Thank you. also try to deal with these files,

[Ben]

This will be because we apply similar streamlining rules as we do to the Affinity documents.  For speed reasons, we append changes to the file, then only periodically "defrag" the file when it reaches a certain % of dead data.

 

So, if you delete stuff, the file will still grow instead of shrink as we write out a new copy of the main file data, but don't do any housekeeping until it reaches 25% redundancy at which point all the dead bits are removed and the file will shrink.

 

You'd have to delete 1/4 of your brushes (approximately) to cause a streamline, though that is subjective.

 

 

[Pšenda]

This is a commonly used technique, but applications can then invoke the defragmentation on demand (see SQLite Vacuum command).

Do you think of something similar?

[Ben]

We have control over when we defrag - and our files are not SQL, so the defragging is our own code.  We just chose to only do it at 25% for these files.  We do it at 33% for Affinity documents.

 

 

[Sergo]

So they will not continue to rise indefinitely, then everything is fine.
Thanks

[Pšenda]

8 minutes ago, Ben said:

and our files are not SQL, so the defragging is our own code.

 

This was, of course, an example.

 

[Polygonius]

Did i get it right? In other words: If i have eg. 20 categorys of new brushes, each with nearly the same size of MB, i have to delete at least 5 categorys (=>25%) of thoose to get an effect of shrinking instead growing? It is (in this case) contraproductiv to delete just 4 categories? In this case the whole monolith-file will go fragmented (rise up) and first defragment after this treshold????

 

Or in complete other words: Should i do not care - that file(s) will do its job after critical mass? 

[R C-R]

32 minutes ago, Polygonius said:

Or in complete other words: Should i do not care - that file(s) will do its job after critical mass? 

Yes, basically. 

[Polygonius]

Are you a dev? What makes you sure? And BTW is AP using another place on the HD for storing its stuff, except its app-folder and this library and of course my personal exports to a place i define? 

(I just have adobe bridge (very nice organizer, so should "our" media-brwoser be), but there are maybe 3 GB of adobe files over the whole system - its absolut nasty).

(I have just a small SSD and each MB is valuable;-) 

[R C-R]

24 minutes ago, Polygonius said:

What makes you sure?

Because Ben said this is the way it works.

[Polygonius]

22 minutes ago, R C-R said:

Because Ben said this is the way it works.

Ah ok, seems i over-read some essential info. Thank you.

[Jowday]

On 3/12/2018 at 1:38 PM, Ben said:

We have control over when we defrag - and our files are not SQL, so the defragging is our own code.  We just chose to only do it at 25% for these files.  We do it at 33% for Affinity documents.

25% is a bit high for a fragmentation threshold, isn't it? My raster_brushes.propcol is a 3GB file even after deleting quite a few brushes. That is perhaps 600 - 700MB of wasted space right there. Foverever if the user doesn't add or remove brushes anymore. Could hurt on laptops with smaller SSD's. Perhaps you should trigger the defrag monthly as well. 

[Pšenda]

6 hours ago, Jowday said:

Perhaps you should trigger the defrag monthly as well. 

Yes, or on demand, as I suggested previously, so the user could compress the files as needed (for example, before sending them to a work partner, customer, etc.)

 

This is the case with browser caches (such as FastStone Viewer), which it creates for faster previewing. The user then cleans the cache (unnecessary thumbnails) and reduces it.

[Jowday]

12 hours ago, Pšenda said:

Yes, or on demand, as I suggested previously, so the user could compress the files as needed (for example, before sending them to a work partner, customer, etc.

Yes also... not or. If you don't understand the issue the service should still run scheduled.

An "optimize" button in the settings could supplement it.

[Jowday]

and... why not sort the brushes ALPHABETICALLY on that occasion... hint hint!!!