On Wednesday 05 April 2006 07:36, D Bera wrote: > > agree about the need for a performance increase in beagle-build-index, > > I (like many others) have found that even its 'incremental' updates > > take a very long time. > > I remember seeing one post on this. I suspect it is because one or > more of these three: > - storing index information in sqlite (as opposed to extended > attributes for normal files backend) Following is a statistic profile from beagle-build-index over an already built index. The top 2 and 3 spots are sqlite. The top spot? Anyone's guess, it doesn't give a library or method name. There were several "addr2line" processes hung up after indexing stopped. I had to kill them, perhaps one would have given the top line. BTW, there is very little disk activity during this. Probably the sqlite database is cached in RAM. Debug: Loaded 50964 records from /var/lib/cache/beagle/indexes/documentation/FileAttributesStore.db in 0.475s Debug: Starting CrawlWorker Debug: Starting IndexWorker Debug: Scanned 69898 files in 6682 directories Debug: CrawlWorker Done Debug: Shutdown Requested Debug: IndexWorker Done prof counts: total/unmanaged: 600001/595252 195074 32.51 % 83212 13.87 % /usr/lib/libsqlite3.so.0 66339 11.06 % /usr/lib/libsqlite3.so.0(sqlite3VdbeExec 26514 4.42 % /lib/libc.so.6 26010 4.33 % /lib/libc.so.6(malloc 25334 4.22 % /lib/libc.so.6(__libc_free 22131 3.69 % /usr/lib/libsqlite3.so.0(sqlite3pager_get 20674 3.45 % /lib/libc.so.6(memcpy 10789 1.80 % /lib/libc.so.6(free 10042 1.67 % /usr/lib/libsqlite3.so.0(sqlite3IsNumber 9314 1.55 % /usr/lib/libsqlite3.so.0(sqlite3BtreeNext 8380 1.40 % /usr/lib/libsqlite3.so.0(sqlite3VdbeSerialTypeLen 6661 1.11 % /usr/lib/libsqlite3.so.0(sqlite3pager_pagecount 6449 1.07 % /usr/lib/libsqlite3.so.0(sqlite3MallocFailed 6193 1.03 % /usr/lib/libsqlite3.so.0(sqlite3MemCompare ...snip... -- Pat Double, pat patdouble com "In the beginning God created the heaven and the earth."
Attachment:
pgpCCQIOcJBVu.pgp
Description: PGP signature