DK5.3.0 AppImg: Speed depends on Filename-length?

[cool.chris65 at web.de]

Hi,

I just made this test:
25 Pics with original canon raw-files and original names (just 8.3) on a local ext4-sata-hdd 
same 25 pic, renamed in the known sheme, same hdd
The database is on a remote mysql-server
Read out the metadata and write them into the database ->
fist test about 5s
test with long filenames needs about 1s per pic

Btw the same test with the files on the nfs was not sigificant slower at all, I think it could 
be max 50% more of time than local

Greetz, Christoph

Am Donnerstag, 17. November 2016, 21:43:32 CET schrieb Gilles Caulier:
> No special reasons... metadata, database do not much be perturbated by the
> name scheme.
> 
> But you use NFS with a NAS? perhaps the problem is here.
> 
> Can you reproduce the time latency when you use a local FS ?
> 
> Gilles Caulier
> 
> 2016-11-17 21:04 GMT+01:00 cool.chris65 at web.de <cool.chris65 at web.de>:
> > Hi,
> > 
> > 
> > 
> > I name my pics usually like img_1234_YYYYMMDD_THHMMSS.jpg. Normally the
> > renaming is allready done during the import from the camera-card, but
> > sometimes (especially older pics) the original names are still present.
> > 
> > 
> > 
> > When I work with such pic (e.g. tagging or geotagging...) it seems to be
> > much faster than after renaming theese pics into the sheme above? Why?
> > 
> > 
> > 
> > System is a i5 at 3.2GHz, 16GB Ram, the collection ist stored onto a NAS
> > (openmediavault with nfs), and the mysql-server for these collection is
> > also running on that NAS (with a dualcor celeron, 12GB RAM, 3x4 TB WD-Red
> > as Raid5 and a dual-eth-connection to the switch
> > 
> > 
> > 
> > Greetz, Christoph
> > --
> > 
> > GPG-Fingerabdruck: B578 8557 B9B1 354B 3A91 1CC0 5E3C 7538 7C91 0837
> > 
> > GPG-Kennung: 7C910837



/*GPG-Fingerabdruck: B578 8557 B9B1 354B 3A91 1CC0 5E3C 7538 7C91 0837*/
/*GPG-Kennung: 7C910837*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20161121/b661cb7a/attachment.html>