CTRL+F extremely slow...

[fbungarz]

Hi all,
In IDI searching the catalog via Label Search was extremely fast. Type a label in the search box, a selection of choices appears, you hit the entry you are looking for and the unfolds, the label popping up almost instantaneously.
In PSu this has become a huge drag!!!
In Catalog - By Category, I have to hit CTRL+F to have the search box pop up. I enter a label name. There is considerable lag-time (1-2 seconds) before the list of choices expands and once I select the label I want to go to, it takes more than a minute (!!!) for the tree to expand and the label to actually pop-up. Sometimes the program even stalls completely and I need to re-start PSu.

Since I have not been using PSu for such a long time, I am not sure if that is in any way related to the new way search is now working in built 2075 or if this is normal (I sure hope not!).
I reported a bug how CTRL+F is now working and Hert quickly announced this will be fixed in the new release (http://mantis.idimager.com/view.php?id=2982). However, the "jumping cursor" has actually become less of an issue now, because CTRL+F is soooo slooooow that it has basically become useless anyway!

After compacting the database, things are slightly better, but not much.
Oddly enough: searching for the same label using the global search box (upper right corner) is almost instantaneous, but then the tree does not update - which can be a bit confusing.
So - global search for a label followed by, open a new tab for the label is MUCH faster than CTRL+F. That is not very convenient.

Could it be that the 2075 update messed up the way PSu now executes CTRL+F?

Thanks,
Frank

[fbungarz]

PS: though strictly speaking the speed itself may not be considered a bug, it means CTRL+F essentially no longer works for the purpose it was designed for (namely quickly jump to a particular label in the catalog tree)

[Mike Buckley]

This capability is typically very fast on my system. I just now tested it four times. Each time the desired label was instantaneously displayed in the popup list. Each time the search was automatically conducted (searching for just one catalog label with no dynamic search) within 2 seconds.

It is not always that fast but it is never as you described and it is never problematically slow. Perhaps it is a bit fast right now because I recently rebooted my computer.

If it matters, my catalog has over 11,000 labels in the hierarchy through which Supreme has to search.

If your system is consistently as slow as you described, my guess is that it has to do with your seemingly unique use of custom XMP, the difficulty you had converting from IDimager to Supreme, etc. But it's only a guess.

You mentioned build 2075. Possibly you're either using an update that has not been publicly released or that's a typo. I'm using build 2074 and checking to determine if there is a later one reveals that I'm using the latest build. It's also possible (I don't remember) that I once updated to 2075 and later reverted to 2074, which might be the reason the system is telling me there is no newer update.

[fbungarz]

Hi Mike,
I am definitely using built 2075! That also is the one for which I filed the Mantis report and the one where Hert recently changed how CTRL+F works.

Don't you remember our discussion about searching for synonyms (http://forum.idimager.com/viewtopic.php ... ch#p111575). You complained it was not working any longer in built 2075. Although I initially reported that it worked, I subsequently corrected myself and filed a bug report.

Is it possible that you reverted back to built 2074, when CTRL+F was no longer working as expected?

That I am using custom XMP cannot possibly affect affect the Label search. CTRL+F searches the catalog tree, i.e., the labels, not the fields attached to these labels (at least I assume it does). Also: even if CTRL+F was searching XMP, then why is the global search so much, much faster? Global search is instantaneous, CTRL+F is a complete drag!

The odd thing is: searching for a label in the search box of the Assign panel is also almost instantaneous. It is only CTRL+F that no longer works (or rather: drags along).

Frank

[vlad]

Frank, are you searching inside the Category view or inside Catalog -> All? (Ctrl-F searches more than labels in Catalog -> All.)

[Mike Buckley]

Is it possible that you reverted back to built 2074, when CTRL+F was no longer working as expected?

It's more likely that I reverted to build 2074 when renaming and changing the position of names of Collections in the Portfolio system stopped working again. Even so, that no longer works with build 2074. It is nice in 2074 that CTRL+F works better, so I'm sticking with it until 2076 or later.

[Mike Buckley]

Frank, are you searching inside the Category view or inside Catalog -> All? (Ctrl-F searches more than labels in Catalog -> All.)

Though I notice no difference in speed on my system, hopefully this is a solution for Frank.

[fbungarz]

Hi Vlad and Mike,
turns out my database is probably malformed
I regularly ran Tools - Compact and PSu always reports the compact/repair finished without errors! Recently I noticed though that the database does not get smaller with that command though. I thought this was odd, because, even though I have gotten used to compact regularly, I usually gained at least a few bytes...
Now, I thought I better check with another tool and tried opening the database in SQLite Expert Personal, a tool that I occasionally used on IDI to test that database for integrity. Opening the PSu database with SQLite Personal tells me the database is "malformed". I checked all my backups, the are ALL malformed!
There are a couple of post on malformed IDI databases and possible fixes using sqlite3 and I am currently trying to see if I can get this to work (e.g.: http://forum.idimager.com/viewtopic.php ... 162#p66410). Sqlite3 also tells me the database (and ALL my backups) are malformed (error message: malformed database schema - near "lowerparent": syntax error

This is REALLY bad news. I worked with PSu regularly for weeks now, regularly did a compact and regularly did backups. But because of their gigantic size I kept only the most recent backups. And they are all malformed.

Converting the IDI database again is of course now not an option. Since using IDI my data has changed so much. Starting with a fresh new PSU database also won't work - that catalog will lack all the label mappings (which are really essential for my workflow!). And I spent several days recently to create new labels that write XMP locality data into the files. About two weeks of work! And then: even if I start fresh, my experience migrating importing folders one-by-one has been very frustrating. Files were mist on import, versions not assigned correctly, etc. etc.
I have spend sooo much time on this and now this!

This is really, really bad.

Frank

[Mike Buckley]

Sorry to learn about the issues, Frank. You'll figure out something. There may be considerable pain along the way but no loss of life or limb.

[fbungarz]

Hi Mike,
thanks for the kind words.
I am trying jgodfrey's solution here: http://forum.idimager.com/viewtopic.php ... 162#p66410

Code: Select all

# sqlite3 copy_of_idi_db.db
.output full.dump
.dump
.exit

# sqlite3 repaired.db
.read full.dump
PRAGMA integrity_check;
.exit

Unfortunately the full.dump file that gets created is empty! Jeff's post is from 2009. Probably the syntax of sqlite3 has changed since the

-- INSERT FOUR LETTER WORD HERE! --


Frank

[fbungarz]

Looks like I am fine. Turns out the version of SQLite Personal that I was using was out-of-date. I just downloaded 3.5.92 and my PSu database opens just fine. I was also able to vacuum and the integrity check tells me everything is OK. I wonder why Sqlite3 gives me the error message: 'malformed database schema - near "lowerparent": syntax error'
Odd...
Anyway - the database is still large, CTRL+F just as slow as ever, but perhaps that'll be fixed once the next built 2076 is going to be released...

-- INSERT BIG SIGH OF RELIEF HERE ---

Frank

[Mike Buckley]

-- INSERT BIG SIGH OF RELIEF HERE ---

Indeed!