I compiled the new version (revision 79e8763) and tried it out on the test
images and also on a copy of my main database. The speed improvement is
considerable; none of the tagging operations I tried took more than seven
seconds to complete. I am looking forward to using this in a stable release.
I have experienced the same kind of delays with tags in the collect module,
but, oddly enough, not with this version -- neither selecting the "tag"
option, nor selecting a tag to collect by, nor applying a color label to an
image in a tag-based collection, took more than two seconds with any
database I tried.
On Thu, Aug 3, 2017 at 4:49 AM, Tobias Ellinghaus <m...@houz.org> wrote:
> Am Donnerstag, 3. August 2017, 09:58:01 CEST schrieb Tobias Ellinghaus:
> > Am Dienstag, 1. August 2017, 23:45:54 CEST schrieb August Schwerdfeger:
> > > I managed to reproduce the problem on a smaller scale using a generated
> > > set
> > > of 5,000 1x1 PNG images, each annotated with a certain number of tags,
> > > with
> > > a total of 6,111 across the set. (I will send you these images in a
> > > separate message.)
> > Thanks for that, I was able to reproduce some glacial speeds with that.
> This should be fixed now in master. Some parts are still really slow with
> many tags though. For example selecting "tag" in the collect module takes
> minutes just to show up for me.
> > > When I imported the first 250 of these images into a fresh database in
> > > Darktable 2.2.4, attaching one new tag to the lot took about two
> > > When I imported all 5,000 into another fresh database, attaching the
> > > tag to the same 250 images took about 10 seconds.
> > >
> > > I also carried out this same test in Darktable 2.0.7. Importing the
> > > images gave me a database file of about 500 megabytes (as opposed to
> > > with Darktable 2.2.4), and the same tag-attachment operation took four
> > > a half minutes. When, however, I repeated the operation with the name
> of a
> > > nonexistent tag in the tagging module text box, it took 10 seconds as
> > > Darktable 2.2.4.
> > What I tried was attaching one new tag to the whole lot. It wasn't fun. I
> > will investigate, but from a first peek it seems that we are spending a
> > of time in sqlite3. So maybe some SQL queries need to be revised, stuff
> > might have to go into a transaction or not be done at all. I will see.
> > > In light of this result, I should mention that the databases I am
> > > this trouble with were all originally created by Darktable 1.4.2 and
> > > over 75 megabytes in size.
> > As it's also slow with a fresh new database we can probably ignore that
> > part.
> > > --
> > > August Schwerdfeger
> > > aug...@schwerdfeger.name
> > Tobias
> > [...]
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org