Hi On 2014-12-15 21:51, J.B. Nicholson-Owens <jbn forestfield org> wrote:
I'm using EasyTAG 2.3.2 on some folders with about 80 FLAC files in them combined. Each FLAC file has multiple images: a front cover, a back cover, a media image, and a lot of leaflet images. All of the leaflet images are common to all tracks. … When I load the folder into EasyTAG, EasyTAG uses about 1.8GB of RAM and then when I select all of the tracks and click the "#" button to set the number of files, I see EasyTAG is using 3.5GB. I'm using the RAM measurements in the GNOME "System Monitor" (like a GUI version of 'top') and free RAM estimates to determine these numbers. I don't understand how counting and setting the track numbering tags requires so much more RAM.
When editing the tag, such as by setting the track number field, the whole tag is duplicated and stored in a history list, so that the edit can be undone. Any images in the tag are duplicated alongside the rest of the tag.
Sometimes I don't have enough RAM to process big hierarchies with lots of images in each file for tasks that don't strike me as needing a lot of RAM to perform (such as numbering tracks). EasyTAG crashes in those circumstances.
When EasyTAG reads from a file, it parses the tag data from the file and copies the results into memory. In this context, tag data are the text fields that are shown in the UI (and any extra fields, for Vorbis comments only) as well as embedded images.
All the text fields are duplicated when the file is inserted into the model which backs the file list (as GtkListStore duplicates values stored in string columns). The text fields of the current file are duplicated when shown in the tag area.
Embedded images are duplicated when showing a file with images in the tag area. More precisely, the image is extracted from the in-memory data and into a GdkPixbuf, before it is scaled and then stored in the model which backs the images list view.
It is possible to avoid some of the duplication, such as by making the file list view read the data directly from the in-memory tag data. This would simplify the file list model substantially, and should save a noticeable (albeit small) amount of memory when large numbers of files are shown.
I'm guessing there's some kind of issue with EasyTAG's RAM use here, but I don't know enough about the structure of the program to identify what that is.
There has never been a better excuse to study EasyTAG's internals and contribute a patch. ;-)
I expect that using a GUI-based tag editor which wants to show me thumbnails of images will require more RAM for caching those images than a CLI-based editor doing the same tagging job would require. But this amount of RAM use surprises me and makes me think something is wrong, particularly when counting taggable files in a directory shows a huge RAM use jump.
It is not really a case of the difference between a CLI and GUI application, but that EasyTAG has poor resource management in general. The undo/redo implementation is rudimentary, and could be improved by sharing the image data if it is identical, or storing a stack of changes (rather than duplicating the tag in its entirety).
Keeping the image data of all files in the file list in memory is a naïve caching mechanism, and there are many ways in which it could be improved. Scaling the image during loading and then discarding the original data might be sufficient, although it would slow down saving (as the images would have to be loaded again). A simplistic approach would be to only load image data when necessary for displaying it in the UI, with no caching. A comprehensive approach might be to use an on-disk cache of images (or just thumbnails), hashing the image data so that there is only one file on disk for each unique piece of artwork, and finally loading the cached image as necessary.
Is this a known issue, or is there a preference I can set to reduce RAM use for big jobs: - make EasyTAG not show me the images (no image processing available)? - make EasyTAG not keep undo data (no undo/redo available)? - make some other change that will let EasyTAG run with lower RAM use?
There is not a setting for this, mainly because it has not been reported as a problem until now. Adding a setting is not appropriate in this case, as fixing the underlying problem (in some fashion) would be equally time-consuming.
-- http://amigadave.com/
Attachment:
signature.asc
Description: Digital signature