Re: Startup performance
Andreas Schleth <schleth_es-S0/[email protected]> Tue, 13 Oct 2020 15:56:15 +0200
| Newsgroups | gmane.comp.kde.kimdaba |
|---|---|
| Message-ID | <[email protected]> |
--===============2840978075728637791== Content-Type: multipart/alternative; boundary="----7G9SW2R01N1ZPG9DDV7S08530JXHRC" Content-Transfer-Encoding: 7bit ------7G9SW2R01N1ZPG9DDV7S08530JXHRC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi coders, As a user, sitting on the side line and occasional submitter of rare bugs = I like to join Martin in thanking you=2E It is just great to see one of my = favourite programs being cared for=2E I had similar ideas about splitting the DB=2E In fact I sort of do it myse= lf since ages: Everybody has her/his own DB and only good pictures are migr= ated via Kim to the family album=2E Which is in a better backup level=2E This works nicely except that it is a bit of a pain to sync category entri= es=2E Which brings me to the point:=20 Would it be possible to have one or more separate category-DBs alongside t= he image DBs? Then splitting it as Martin proposed would be a better user experience=2E = When setting up a new DB you could possibly choose from which Category tree= to inherit and have all meta data to choose from from image1 on=2E Best regards, Andreas Am 13=2E Oktober 2020 07:50:37 MESZ schrieb "Martin H=C3=B6ller" <martin@x= ss=2Eco=2Eat>: >Hi! > >Am 12=2E Okt=2E 2020 schrieb Robert Krawitz: > >> It really is the startup that's the most visible aspect of all of >this=2E Again, that either means >> pretty fundamental changes in the storage backend, a faster XML >parser, or maybe a way of bringing >> up the UI while images are still loading (and since you're often >going to want to look at your most >> recent photos, not even very helpul)=2E If we stored photos in the >database in _reverse_ order of >> time, though, that might be workable (I'd love to have instant access >to my most recent basketball >> game while the rest of the file is being loaded)=2E > >Just an idea: what about "partitioning" the database=2E I mean we could >have a single XML file per year, per decade, per 10k images or >whatever=2E >That way, loading the more recent images first as Robert suggested >would >be easier=2E > >Oh and BTW, thanks for all the work that has be done on KPA so far! >Really great work! > >hth, >- martin --=20 Diese Nachricht wurde von meinem Android-Ger=C3=A4t mit K-9 Mail gesendet= =2E ------7G9SW2R01N1ZPG9DDV7S08530JXHRC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head></head><body>Hi coders,<br>As a user, sitting on the side line = and occasional submitter of rare bugs I like to join Martin in thanking you= =2E It is just great to see one of my favourite programs being cared for=2E= <br>I had similar ideas about splitting the DB=2E In fact I sort of do it m= yself since ages: Everybody has her/his own DB and only good pictures are m= igrated via Kim to the family album=2E Which is in a better backup level=2E= <br>This works nicely except that it is a bit of a pain to sync category en= tries=2E Which brings me to the point: <br>Would it be possible to have one= or more separate category-DBs alongside the image DBs?<br>Then splitting i= t as Martin proposed would be a better user experience=2E When setting up a= new DB you could possibly choose from which Category tree to inherit and h= ave all meta data to choose from from image1 on=2E<br>Best regards, Andreas= <br><br><div class=3D"gmail_quote">Am 13=2E Oktober 2020 07:50:37 MESZ schr= ieb "Martin H=C3=B6ller" <martin@xss=2Eco=2Eat>:<blockquote class=3D"= gmail_quote" style=3D"margin: 0pt 0pt 0pt 0=2E8ex; border-left: 1px solid r= gb(204, 204, 204); padding-left: 1ex;"> <pre class=3D"k9mail">Hi!<br><br>Am 12=2E Okt=2E 2020 schrieb Robert Krawi= tz:<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 1ex 0= =2E8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">It really is th= e startup that's the most visible aspect of all of this=2E Again, that eit= her means<br>pretty fundamental changes in the storage backend, a faster XM= L parser, or maybe a way of bringing<br>up the UI while images are still lo= ading (and since you're often going to want to look at your most<br>recent = photos, not even very helpul)=2E If we stored photos in the database in _r= everse_ order of<br>time, though, that might be workable (I'd love to have = instant access to my most recent basketball<br>game while the rest of the f= ile is being loaded)=2E<br></blockquote><br>Just an idea: what about "parti= tioning" the database=2E I mean we could<br>have a single XML file per year= , per decade, per 10k images or whatever=2E<br>That way, loading the more r= ecent images first as Robert suggested would<br>be easier=2E<br><br>Oh and = BTW, thanks for all the work that has be done on KPA so far!<br>Really grea= t work!<br><br>hth,<br>- martin<br></pre></blockquote></div><br>-- <br>Dies= e Nachricht wurde von meinem Android-Ger=C3=A4t mit K-9 Mail gesendet=2E</b= ody></html> ------7G9SW2R01N1ZPG9DDV7S08530JXHRC-- --===============2840978075728637791== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KPhotoAlbum mailing list [email protected] https://mail.kdab.com/mailman/listinfo/kphotoalbum --===============2840978075728637791==--