An Indexing Suggestion
It seems rediculous to me to force my computer to build an index of libronix resources. Each Libronix resource should have its own prebuilt index. Then the indexer can just combine indexes or the search engine can read through the index files.
Comments
-
RichardHendricks said:
It seems rediculous to me to force my computer to build an index of libronix resources. Each Libronix resource should have its own prebuilt index. Then the indexer can just combine indexes or the search engine can read through the index files.
Richard, searching individual indexes (as in Logos 2) would take forever for those of us with large libraries.
Once your index is built you will see the benefits. In Beta 1, one of my computers took 24 hours to index. 1 resource took 1 hr 45 minuts!!!! That has improved.
0 -
I understand the benefits of indexing. What I object to is the fact that MY COMPUTER has to build the index from SCRATCH. I cannot help but think that it would be faster to have an indexer that COMBINED INDIVIDUAL INDEXES.
I also object to the indexer STARTING OVER FROM SQUARE ONE when interrupted. Leaving the computer on overnight is not an option for me.
0 -
RichardHendricks said:
It seems rediculous to me to force my computer to build an index of libronix resources.
Alas, there's not really any alternate solution (without much worse problems). If we index each book separately, every book has to be searched separately. If we index them separately and try to merge the indices on your system, it takes a long time, too. (It's a huge amount of data.) And then we can never improve the search engine, because we're then locked into the limitations it had the day those books were built. And we can't even improve it for new books, because they'd be incompatible for merging with the old ones you have.
We're working on little things to speed it up, and we hate it as much as you do. But it's the key to fast searching, and we are doing it the best ways we know, using the latest academic research and wisdom on the topic.
0 -
RichardHendricks said:
I also object to the indexer STARTING OVER FROM SQUARE ONE when interrupted. Leaving the computer on overnight is not an option for me.
The indexer uses memory. It slows down when it has to write temporary information to the disc. If you want it to be interruptible, with the machine turned off, it has to (constantly) write everything to disc, in case you shut down at that moment. That REALLY slows things down. And takes a huge amount of code to manage organizing the data in memory and serializing/deserializing that intermediate data to the hard drive.
0 -
RichardHendricks said:
Each Libronix resource should have its own prebuilt index. Then the ... search engine can read through the index files.
We tried this. It's called Libronix DLS 3. [:)]
(Yes, I did see your suggestion about merging indexes, but thought that it had already been covered above.)
0 -
RichardHendricks said:
Leaving the computer on overnight is not an option for me.
Hi Richard,
On principle, I don't leave my laptop running over night, either. And as a beta tester who went thru many multi-gig downloads, I was faced with that prospect repeatedly. What I've discovered is that the indexer tolerates well being put to sleep (vs. turned off). It happily resumes when the laptop is waked up. And it doesn't lose anything it's done. That solution has worked well for me MANY times, since... For example, I receive an early morning "update" that has to be reindexed. I have to leave for work before reindexing is finished. My home laptop is also my work laptop, so it HAS to travel. Just put it to sleep instead of shutting it off. The laptop seems smart enough to deal with the change of configuration (I have a port replicator at home & at work, & each has different peripherals attached). And that has been a workable solution for indexing without having to restart. (I agree: that'd have been intolerable.)
Hope this helps...
Bill
Grace & Peace,
Bill
MSI GF63 8RD, I-7 8850H, 32GB RAM, 1TB SSD, 2TB HDD, NVIDIA GTX 1050Max
iPhone 12 Pro Max 512Gb
iPad 9th Gen iOS 15.6, 256GB0 -
Maybe a compromise solution would be to allow the user to determine which resources get indexed. Logos packages have hundreds of resources and maybe some of you use most of them, but I would expect most people will regularly use a small subset of available ones... If an unindexed resource is needed subsequently, then Logos could offer the option to add that one to the index. As the indexes are stored in SQLLite databases I would think this would be a viable option...
In similar fashion, it would be better if Logos4 offered to allow users to pick which resources are downloaded. If I purchased a Base Product (which I haven't) I probably would not use or need half of it - so the option to just download the bits of it I needed now would be useful. Of course, Logos3's updater does allow a pick and choose approach.
This sort of option would allow a user to get up and running quickly, and maybe download the less used resources overnight, at their leisure...
0 -
Sorry to say my friend, that would be a complete disaster, after many discussions on this I have to side with Bob and Logos, they have used the best technology available to them, and had they not it would be like wading throught treacle to find the peanut.
The indexing is a pain but for most people will be a once only occurrence.. in a few weeks you wont even remember the indexing... plus with upgrades it can only get faster...
I also hate to differ (and might be wrong) but believe the index file (as far as I can asceertain) is Emdros.
Never Deprive Anyone of Hope.. It Might Be ALL They Have
0 -
The only way this would make any sense is if they did a quicky first index of top stuff and then did the full one. We could use the quicky to get our feet wet while waiting for the real one. But besides figuring out what are the first ones to index fairly and the fact that some of these would be reverse interlinears that index slowly, all this work for the quicky would be wasted time in the long run.
Now if Logos had figured out how to get a collection index onto the installation DVD, then that might make sense, but that also has issues.
The Gospel is not ... a "new law," on the contrary, ... a "new life." - William Julius Mann
L8 Anglican, Lutheran and Orthodox Silver, Reformed Starter, Academic Essentials
L7 Lutheran Gold, Anglican Bronze
0 -
DominicM said:
I also hate to differ (and might be wrong) but believe the index file (as far as I can asceertain) is Emdros
Looks like you've nailed it.
http://emdros.org/proventechnology.html
Speaking from the IT side of the pond, that looks fascinating.
AKA WillyBurger
0 -
Look at http://emdros.org/faq.html and scroll down to the "Which database back-ends are supported?" question.
Emdros is a smart tech that, in Logos, is storing the index in SQL Lite tables. Regardless, I have no issues with the tech, my suggestion is how to use the tech. And I'm not saying Logos's implementation is wrong per se, but that they could consider enhancing it further by offering users the options to: a) not download something in a package (because they don't want it) and b) only index certain books (for similar reasons).
For those of us with slow computers and limited Internet download amounts, these would make a difference.
Just my 2 cents...
0 -
DominicM said:
I also hate to differ (and might be wrong) but believe the index file (as far as I can asceertain) is Emdros
Emdros is used for syntax searching, but the full-text engine is a highly tuned in-house creation, based on the academic research on full-text information retrieval.
0
