Slow startup on Windows #832
Comments
|
What's |
|
Confusingly, Win32 is what you're running when you use 64-bit Windows 10... it's just Microsoft's standard name for the Windows API (yes, it's crazy, it also is what it's called under 64 bit windows). I'm also running 64 bit Windows 10. |
|
Oh, and I just installed Ginga under windows using conda as follows:
I'm not sure which graphics backend it is using (probably Qt?). |
|
If you run Ginga like this: Do you see something like this? Ginga also runs the code in Also, I am curious if you still have the same problem with the dev version of Ginga, which you can install into your |
|
Hey, thanks, that was an incredibly useful suggestion! I see now I am running under Qt in both cases. The slow startup appears to be associated with trying to load a bundled font (roboto), which takes 28s under the Windows API vs. about 0.2s in WSL! Here's the output under both systems (using the standard version, but I also verified that the problem is still there after installing the development version). Windows API (base) § Blackbird2 {~\Desktop} ginga --loglevel=20 --stderr WSL: (base) abraham@Blackbird2:~/git$ ginga --loglevel=20 --stderr |
|
Huh... Do you have a lot of fonts installed? What if you fire up the Python interpreter and run the following? Any of these commands take 40s? >>> from ginga.fonts import font_asst
>>> font_asst.get_loadable_fonts()
['roboto']
>>> font_asst.get_font_info('roboto')
{'name': 'roboto', 'font_path': 'd:\\...\\ginga\\fonts\\Roboto\\Roboto-Regular.ttf'} |
|
And if those are not slow, what about this? >>> from ginga.qtw import QtHelp
>>> QtHelp.load_font('roboto', the_path_you_get) |
|
Nope! Those commands all run more-or-less instantly and seem to produce sensible outputs. |
|
Maybe @ejeschke knows where to poke at next. I can't reproduce this slowness on my Windows. Thanks for checking! |
|
Your other font suggestion ran OK too: I'll wait to see if Eric can suggest anything, and thanks a million for helping diagnose this! |
Hi Roberto. Is this from WSL though? or the Windows Command (DOS-type) shell? |
|
Good guess on the fonts, @pllim! @robertoabraham, just to make sure it is not some other sort of legacy issue unrelated to fonts, can you temporarily rename any |
|
Hi Eric, I was running those commands (to check the font loading) from PowerShell (you can verify it from the windows-style file path for the fonts). The font takes a second or so to load (max). I just zapped the .ginga file from my home directory and let ginga recreate it and then started up ginga a few times. I still get the same behavior I'm afraid. Here are the first three lines from the run log (from which it seems it takes about 35s to load the font). It's very weird! |
|
I don't use PowerShell. I have Git Bash, which can see my Miniconda, and I run everything from Git Bash. I wonder if this is a problem it PowerShell rather than in Ginga. 🤷 |
|
I don't think it's PowerShell. I just tried it using cmd.exe (the standard DOS prompt thing) and got the same behavior. I'm starting up python using the items in the Anaconda folder in the start menu. If you think it is worth a try I can uninstall Anaconda and reinstall (though it would be a hassle so I'd rather not unless you're out of ideas). |
|
@robertoabraham, do you have a lot of fonts installed on your system? |
|
How about running one of the Qt example programs from your git checkout: python ginga/examples/qt/example2_qt.py --loglevel=20 --stderrstarts up fast? Dragging a file into the window loads ok? |
|
Well, I'm not sure what counts as a lot of fonts these days! My |
|
No, that seems quite reasonable. Just asking, because some searches were suggesting that if there are thousands of fonts installed, Qt font management can sometimes get bogged down. |
|
The Qt example program ran pretty quickly. It took perhaps a couple of seconds to start. |
|
Hmm... I just noticed that dragging a FITS file into the window of qt/example2_qt.py results in an error. However, loading the file by clicking the 'Open File' button works fine. Not sure if that's relevant or not... |
|
Let's check whether this is a problem with just def init_config(setup):
from ginga.fonts import font_asst
font_asst.remove_font('roboto')
font_asst.add_font("/path/to/some/font/FontName.ttf", font_name='roboto')Replace the font path with the one from your installation. Start up Ginga as before, and let us know the result. Tnx! |
No, probably a bad assumption about paths in the example drag-drop handler. But we should open a separate ticket about that... |
|
I just tried replacing roboto with courier but I'm afraid it still took forever to load. |
|
@robertoabraham, appreciate your patience! Could you try copying the fonts from |
|
I think this def init_config(setup):
from ginga.fonts import font_asst
font_asst.remove_font('roboto')
font_asst.add_alias('fixed', 'Courier')Does this speed up things? |
|
Hi Eric, I think we have been going down a rabbit hole! So I just edited my The slowdown seems to be associated with something going on right after starting main.py, regardless of what that thing is. I smell a rat... maybe something like a virus checker is kicking in or something. I'm going to disable all virus checking temporarily to see if that makes a difference. |
Excellent. We'll have to narrow it down further. There was a similar issue posted earlier, for Ginga on Debian. Something about downloading documentation files or astropy files or something. We'll have to try searching the issues... |
|
Well, whatever is going on it's not my virus scanner... I disabled it and rebooted the machine to make sure it was really off, and then re-ran ginga and it still took over 30s to load. It's a real puzzler. Whatever is going on it appears to happen after this line is logged:
Anyway, I'm going to drink a beer so no more debugging from me today (but first I'm going to reactivate my virus scanning!). And of course I can always use ginga from WSL. Thanks so much for looking into this stuff and hope you enjoy your holiday weekend! Bob P.S. Not to be a fanboy, but thanks again for Ginga. I really love it. |
|
🍺 Cheers! this is the issue I was thinking about. However, it looks like that was specific to the Debian version and was fixed. I think the next thing to try (whenever you get back to it) is to run the program with I think you are right that the font stuff is a red herring. Just FWIW, it would also be useful to know the version of |
|
Hi Eric, I got a chance to look into this issue by starting up ginga with --loglevel=10 on my windows laptop again. I've attached a text file with the startup log. The slow bit now appears to be associated with a QT widget, which took 30s. Here's a snippet showing what's going on: Does this help to pin down the issue? Thanks, Bob P.S. Can it be 12 days since I first posted this issue? Man the days blend together when one isn't supposed to leave the house because the coronavirus social distancing. |
|
Oops, I forgot to attach the log in my previous message. Here it is: |
|
I think the only thing of significance happening in those lines (in 2020-04-22 16:07:44,065 | D | Task.py:1048 (startall) | startall done
2020-04-22 16:07:44,098 | I | Control.py:168 (__init__) | trying to load bundled font 'roboto'
2020-04-22 16:07:44,108 | D | Desktop.py:264 (switch_page_cb) | page switch: <ginga.qtw.Widgets.Splitter object at 0x7f2108038090>
2020-04-22 16:07:44,122 | D | Desktop.py:264 (switch_page_cb) | page switch: <ginga.qtw.Widgets.VBox object at 0x7f20e80185d0>
2020-04-22 16:07:44,133 | I | ModuleManager.py:71 (load_module) | Loading module 'Operations'...and on my Mac laptop it looks like this: 2020-04-22 16:19:34,445 | D | Task.py:1048 (startall) | startall done
2020-04-22 16:19:34,765 | I | Control.py:170 (__init__) | trying to load bundled font 'roboto'
2020-04-22 16:19:34,774 | D | Desktop.py:264 (switch_page_cb) | page switch: <ginga.qtw.Widgets.Splitter object at 0x10314f6390>
2020-04-22 16:19:34,958 | D | Desktop.py:264 (switch_page_cb) | page switch: <ginga.qtw.Widgets.VBox object at 0x10359a1b10>
2020-04-22 16:19:35,175 | I | ModuleManager.py:71 (load_module) | Loading module 'Operations'...In both cases there is no significant delay in those lines. @pllim, can you run it on your Windows laptop with |
I'm beginning to suspect @pllim is right that this has something to do with the environment set up by the shell. @robertoabraham, do you have any students who are seeing this same slow startup? |
|
@ejeschke term just ended so I can't easily check with undergrads (all my grad students and postdocs are using Macs or Linux boxes), but I think what I'll do is find some old Windows machines and install AstroConda on them to see what happens (or maybe I will just nuke my current laptop's setup from orbit and reinstall everything) and see if this goes away. Might take a few days, but it'll happen and I'll report back! |
This comment has been minimized.
This comment has been minimized.
|
@robertoabraham, can you post the same lines when launching from WSL? |
|
@ejeschke Sure! Here's the corresponding output when starting ginga from WSL: |
|
Definitely a bit faster on RHEL 7: Disclaimer: They are not exactly the same dev versions on both OS, but I don't think that matters that much? |
|
Hmm.. is the |
|
Sorry, I was on a PR branch. This is the log from latest |
|
Here's @robertoabraham's extract from the WSL startup: 2020-04-23 15:49:30,762 | D | Task.py:1048 (startall) | startall done
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-abraham'
2020-04-23 15:49:30,799 | I | Control.py:171 (__init__) | trying to load bundled font 'roboto'
2020-04-23 15:49:30,819 | D | Desktop.py:264 (switch_page_cb) | page switch: <ginga.qtw.Widgets.Splitter object at 0x7fb180081160>
2020-04-23 15:49:30,826 | D | Desktop.py:264 (switch_page_cb) | page switch: <ginga.qtw.Widgets.VBox object at 0x7fb1800b01d0>
2020-04-23 15:49:30,891 | I | ModuleManager.py:71 (load_module) | Loading module 'Operations'...So a HUGE difference, about 10 milliseconds between the two |
I don't think so. The lag comes in |
Hi, on my laptop it appears that ginga takes over 10x longer to start up in native Win32 mode than it does when running under the windows subsystem for Linux (WSL). On the same machine, running Anaconda python 3.7.3, ginga takes about 40 seconds to start up under win32, while on the exact same machine starting ginga in WSL takes just 3s.
I've run this multiple times on win32 to verify it isn't just a caching thing and did the tests at more-or-less the same time under identical loads.
Once ginga has started up as far as I can tell ginga is running fine in both Win32 and WSL modes.
I'm personally OK with using WSL for everything so this issue isn't biting me, but I'd like to start encouraging our undergrads to use ginga and many (in fact most) of them want to use Windows without having to deal with installing the Linux subsystem and an X11 server, so it would be great if the startup times under Windows Win32 and WSL were in the same ballpark.
All the best,
Bob Abraham
The text was updated successfully, but these errors were encountered: