[Shotwell] Call for testing, round 2

[Jim Nelson]

Thanks Roman.  Yes, we will be working on performance improvements in 0.5.
Until then, we've added a ticket for 0.4, to show a progress bar (as a kind
of splash screen) when loading a library over a certain size:

http://trac.yorba.org/ticket/1198

Thanks,

-- Jim

On Fri, Dec 18, 2009 at 12:54 AM, Roman Yepishev
<roman.yepishev at gmail.com>wrote:

> On Thu, 2009-12-17 at 19:44 -0800, Jim Nelson wrote:
> >
> > We're really excited about the response we received this week to our
> > call for testing -- you all really worked the code paths, and I want
> > to thank you for that.  Some of the issues you've brought to our
> > attention we've ticketed for the next release, but we worked hard this
> > week to resolve the most egregious ones.
> Thanks!
>
> Since (as you may already know) I have a pretty large amount of photos
> (14204 as of now) there is a pretty noticeable delay for startup.
>
> Even after several launches (i.e. sqlite db might be completely in
> memory cache) it takes 20 seconds from typing 'shotwell' till the main
> window appears. There is a bug report describing this issue, #1118[1].
>
> In case this is not that easy to fix, I would suggest that some sort of
> startup indication might be needed (splash screen, startup-notification,
> etc.
>
> Imagine a user that installed shotwell, started it up (quick startup, no
> photos in db). Imports her collection of photos since dinosaur era,
> browses them (really quick, so the impression would be "wow, it is
> FAST!") then quits Shotwell. Afterwards she wants to browse the photos
> again, selects "Shotwell" from the menu and... nothing happens.
>
> Then Shotwell appears after 20+ seconds. What is strange is that no disk
> activity accompanies this on subsequent startups.
>
> As I can see from strace output this block repeats 2 thousand times:
>
> fh 8 is
> 10:38:49 open("/home/rtg/.shotwell/data/photo.db", O_RDWR|O_CREAT|
> O_LARGEFILE, 0644) = 8
>
> 10:38:49 access("/home/rtg/.shotwell/data/photo.db-journal", F_OK) = -1
> ENOENT (No such file or directory)
> 10:38:49 fstat64(8, {st_mode=S_IFREG|0644, st_size=4833280, ...}) = 0
> 10:38:49 _llseek(8, 24, [24], SEEK_SET) = 0
> 10:38:49 read(8, "\0\0\345\371\0\0\0\0\0\0\16#\0\0\0\203", 16) = 16
> 10:38:49 fcntl64(8, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET, start=0,
> len=0}, 0xbff476c8) = 0
> 10:38:49 fcntl64(8, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET,
> start=1073741824, len=1}, 0xbff47298) = 0
> 10:38:49 fcntl64(8, F_SETLK64, {type=F_RDLCK, whence=SEEK_SET,
> start=1073741826, len=510}, 0xbff47298) = 0
> 10:38:49 fcntl64(8, F_SETLK64, {type=F_UNLCK, whence=SEEK_SET,
> start=1073741824, len=1}, 0xbff47298) = 0
> 10:38:49 access("/home/rtg/.shotwell/data/photo.db-journal", F_OK) = -1
> ENOENT (No such file or directory)
>
> ...
> 10:39:11 read(8, "\0\0\345\371\0\0\0\0\0\0\16#\0\0\0\203", 16) = 16
>
> Hope this might help a little.
>
> [1] http://trac.yorba.org/ticket/1118
>
> --
> Roman Yepishev <roman.yepishev at gmail.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.gnome.org/archives/shotwell-list/attachments/20091218/b184b728/attachment.html>