I had been doing a bunch of other things, but then closed a Bible Word Study panel and it took upwards of 15 seconds to close. Here's the log file.
3542.Slow_BWS_Closing.zip
Logged on wiki: http://wiki.logos.com/Bug$3a_(Performance)_Very_slow_closing_BWS_panel
Rosie,
Unfortunately, I can confirm this [:(]
Rosie, can you be more specific. I ran a study on God using greek resources inlcuking the LXX and it responded right away. I am using the latest beta.
Lynden,
Now close the BWS panel and start the stopwatch... [;)]
It responded right away. Ran a word study on the english word God, greek logos, closed it and presto it closed. Must be the cold weather you folks experiencing. [:)]
Using HP G71 Windows 7, 64Bit, 4 Ram, 3.0 processor.
Yes, sometimes it is fast for me too. But here are steps to consistently reproduce the slow version:
Create a custom BWS template with just the Translation section in it, call it, say "BWS - Translation."
Open ESV, go to Gen 3:15, open Interlinear pane
Click on "he" in Gen 3:15 to scroll interlinear pane to that word
Right click on the Lemma for he ("הוא") - select Lemma tab on right of pop-up menu, and "BWS - Translation" from left side.
Click on the word "he" in BWS graphic to expand it out and show all places where it occurs (we're alreading grinding to a pretty slow speed by this time!)
Click the X to close the BWS window and start a stopwatch....... It took 35 seconds to close!
Will try again to reproduce this after a reboot, but it's completely consistent even after shutting down and restarting Logos.
Rosie I concur. Just clicking the word in the center of the graph and Logos stops responding for a while. Closing it took 23 or more seconds. I got a not responding message for a while. Never got it to expand.
Yup, clicking "he" to get the list of places where that occurs took a really long time, too. About 22 seconds this time. Here's a new log with this experiment done after a cold boot and nothing else running. (Except my Windows Date & Time clock with a second hand and DeskPins to keep it up on top. But it runs slowly even without the clock so it's not a "Heisenbug" [:)] ) It takes 32 seconds to close the BWS window in this test. It appears that absolutely nothing is happening for about the first 29 seconds and then I start to hear hard disk noises.
0677.SlowCloseBWS.zip
I have been reporting issues with this since the Private Beta.
It has been confirmed as a bug in this recent thread.
http://community.logos.com/forums/t/8970.aspx
I hope we see this fixed in the near future - I really like the BWS, but this bug can make it quite frustrating to work with.
I believe this is a duplicate of http://wiki.logos.com/Bug$3a_Bible_Word_Study_(BWS)_hangs_when_clicking_ring_graph_segment_for_common_word (because it's removing the verses from the display when you close the panel).
it's removing the verses from the display when you close the panel
Am puzzeld by this, why not just destroy/close the panel?? presumably you recreate/redraw it each time its called..
seems a waste of processor time to me
it's removing the verses from the display when you close the panel Am puzzeld by this, why not just destroy/close the panel?? presumably you recreate/redraw it each time its called.. seems a waste of processor time to me
Precisely! Why bother removing the verses one by one? Sure it's a problem that it was slow to put them there in the first place. But this seems like a separate issue to me.
EDIT: However I see that the original poster did mention both issues in the original bug report. Rather than completely remove mine as a "duplicate" perhaps I should link to this thread in that first bug report for further info. The fact that I've posted logs might be helpful in debugging the problem.
What do you think, Bradley?
it's removing the verses from the display when you close the panel Am puzzeld by this, why not just destroy/close the panel?? presumably you recreate/redraw it each time its called.. seems a waste of processor time to me Precisely! Why bother removing the verses one by one? Sure it's a problem that it was slow to put them there in the first place. But this seems like a separate issue to me.
I haven't debugged it, but my guess would be that it's WPF tearing down the visual tree that is taking the time; we try pretty hard not to perform operations that take 15-20s on the UI thread.
EDIT: However I see that the original poster did mention both issues in the original bug report. Rather than completely remove mine as a "duplicate" perhaps I should link to this thread in that first bug report for further info. The fact that I've posted logs might be helpful in debugging the problem. What do you think, Bradley?
That sounds useful.
I haven't debugged it, but my guess would be that it's WPF tearing down the visual tree that is taking the time...
That sounds absurd (not your comment, but the underlying design of WPF if that's true about it). I don't know WPF at all, but what kind of display engine needs to create a "tree" of such complexity that it takes on the order of 30 seconds to dismantle it and make it disappear from the screen? I wonder who on the WPF architecture team failed "Algorithms and Data Structures" in college? (Or never took such a class.) Even if it does make sense for WPF to use a tree to store the visual info, trees are relatively simple data constructs. It doesn't take half a minute to free the memory used by them. I'm truly mind-boggled at this inefficency.
You're doing great work, Bradley. Don't worry. I'm not fuming, nor am I directing any of my speechless incredulity at you. Just really mystified, and I sometimes like to use hyperbolic language to express myself. [:)]
I'll go ahead and link that other bug to this thread. Thanks!
