Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#20 Removing "text filter" with a large DB freezes OCM

open
nobody
Database (3)
5
2012-10-15
2011-02-25
floppgc
No

I have a OCM database of about 6000 caches, which is loaded quite fast at startup. Filtering by text (upper right text box with magnifying glass icon) also works nice and shows the matching caches. But when removing the text filter (by clicking on the "x" button next to the text box or by manually removing the text from the text box), OCM endlessly displays "Refiltering, please wait..." in the status bar and seems to freeze.
With a much smaller DB (some hundered caches) it works well.

Is my DB just to big?

Discussion

  • kmcamp_ott
    kmcamp_ott
    2011-02-25

    I'd consider this to be a performance bug, I'll see what I can do. Is this in 0.23?

    Basic Filters (text, distance and status above the cache list) are in-memory filters and don't actually go to the underlying database. This actually makes searching by text a little faster and easier, and you'll notice it's searching both cache codes and cache names at the same time. Refiltering the list shouldn't take that long though, even if it's fairly large. I run about 5500 caches in my DB, but I know a number of users have more like 12000 to 15000 caches in their DB.

     
  • floppgc
    floppgc
    2011-02-27

    This happens in 0.23.6 (and previous versions).

    I just found out, that this behaviour only occurs when selecting a cache from the list:

    There is no problem with adding a text filter such that a single cache is shown in the list, then removing the filter again. After some seconds the full list is shown again.

    There is a problem when you add a text filter such that a single cache is shown, then selecting this cache from the list, and removing the text filter again. Now OCM "refilters" forever.

    Very strange...

     
  • kmcamp_ott
    kmcamp_ott
    2011-02-27

    Can you include some screenshots of what you're doing? I can't seem to get that to hang in my OCM.

    Also, what linux are you using?

     
  • floppgc
    floppgc
    2011-02-27

    Screenshots attached.

    Steps to reproduce the buggy behaviour:
    1. Open OCM with a reasonably large DB
    2. Add a text filter such that only one cache is visible
    3. Select this cache by clicking on it
    4. Remove the filter again ("x" button)
    5. Freeze

    I'm using Ubuntu 10.10

     
  • kmcamp_ott
    kmcamp_ott
    2011-02-27

    I think I'll have to try this in 10.10 (I'm on 10.04). My database is only a little bit smaller then yours (5597 caches versus your 5823) but after I hit the clear button it refilters in a couple of seconds. I also tried this on my wife's netbook, her DB is a little smaller at 4000 caches, but the netbook is much much slower then my laptop, however her machine is also 10.04.

     
  • kmcamp_ott
    kmcamp_ott
    2011-03-07

    For 10.10, are you using Unity or just the regular Gnome desktop?

     
  • floppgc
    floppgc
    2011-03-07

    I'm using the regular gnome desktop.

    If OCM was written in C++ and Qt, I would be able to debug it on my own ;)

     
  • floppgc
    floppgc
    2011-03-08

    Just played around with the source code of 0.23.9 a little bit.

    The critical part seems to be the call of "m_QuickFilter.Refilter ();" in the method "public void RefilterList ()" in "Widgets/CachesList.cs". I added a few lines around this call to compute the time needed for refiltering the list.

    Then I created a new cache db with only 500 caches and started the usual procedure:

    Entering a quick text filter such that only a few caches are shown in the list, and then removing then filter again triggers the "RefilterList" method. In this case, the critical "m_QuickFilter.Refilter()" takes some milliseconds to finish. Everything fine.

    When doing almost the same but selecting a cache before removing the filter, "m_QuickFilter.Refilter()" takes 6 seconds to finish!

    So my original thought that OCM freezes on the original DB containing 6000 caches is wrong. Actually it "refilters" veeeeeeeeeeeery slowly.

    Strange.

     
  • kmcamp_ott
    kmcamp_ott
    2011-03-08

    Could you email me your DB? I'm installing a 10.10 VM and will see if I can reproduce using your data. On 10.04 and Suse there's no real difference in the refilter speed whether or not a cache is selected.

     
  • floppgc
    floppgc
    2011-03-09

    Hm. Not reproducible on a 10.04 machine :(
    I will try on a different 10.10 installation...

    Maybe it is an issue of mono/gtk on 10.10?

     
  • kmcamp_ott
    kmcamp_ott
    2011-03-09

    I'll setup a 10.10 machine today. I've just been really busy lately and hadn't gotten a chance to build a new VM (my old 10.10 VM stopped working)

    Now I know that at least I wasn't missing a step, since you can't reproduce it either in 10.04. Fortunately, your investigation I think tells me how to fix this. I can clear the selection in the list before the refiltering happens.

     
  • kmcamp_ott
    kmcamp_ott
    2011-03-10

    in my 10.10 VM I couldn't get it to fail either with my PQ (1000) or your test.ocm. I'll switch my VM from English to German to be sure though.

    However, I did notice a bug I didn't on my real machine, that basic filters are disabled unless an advanced filter is applied, I'll definitely fix that. I can also try a "stab in the dark" fix of clearing the selection, refiltering, and then selecting the cache again. It won't break anything, and it should fix this problem your hitting.

     
  • kmcamp_ott
    kmcamp_ott
    2011-03-13

    Didn't get the trial fix into 23.10, will try for 23.11

     
  • kmcamp_ott
    kmcamp_ott
    2011-03-28

    This happened to me today...though I couldn't get it to happen again. My "shot in the dark" obviously wasn't the problem.

     
  • kmcamp_ott
    kmcamp_ott
    2011-03-28

    Now this happens to me all the time... It seems like it might be a bug in GTK itself. I'm working on finding a solution

     
  • floppgc
    floppgc
    2011-03-29

    Hm. These are bad news. I guess a bug in GTK is very hard to debug.

     
  • kmcamp_ott
    kmcamp_ott
    2011-03-29

    It's actually a good thing that it's happening to me now because at least I can see what's going wrong :) Reproducing a bug like this is actually the hard part, fixing it isn't usually too tough. It'll get fixed for 0.23.14

     


Anonymous


Cancel   Add attachments