Set optlevel to 1 #520
Set optlevel to 1 #520
Conversation
|
Are there any negative implications? So is the generated code slower? |
|
Presumably it's a bit slower, although I'm simply unsure of whether it would be easily detectable. Can you think of places where performance matter much? Of course Gtk's rendering is performance sensitive, but that's handled by the C library and the Julia code mostly dispatches to Gtk. Maybe signal-handling? Though there too I have a hard time imagining that changing something from 100ns to 200ns would make a measurable difference. I'm in no hurry to see this merged. I'm running with it locally, perhaps you may want to try that too and see if it causes any problems. If we both like it after a month, then maybe we should merge. |
|
I am fine with this being merged. Currently the TTFP issue is for Gtk the more pressing issue IMHO. Testing is a little bit difficult for me. I have a large applications where some callback are extreme slow the first time. In one case its about a minute. In addition the entire application requires about 30 seconds to start up (TTFP). But I am using quite some UI unrelated stuff when starting the UI so my feeling is more that its invalidations in a different code path, which makes it so slow. But back to the point: We still have this issue that the REPL gets sluggish when Gtk signal handling is running in a timer. This is one of the code paths where I would say that we still have issues compared to a simple C Gtk application. Don not know if the optlevel change impacts that. |
|
I'm not on Windows so it's not easy for me to test, but I'd be surprised if this substantively changes the event loop issue. If your startup slowness is due to invalidations, definitely give nightly a try, it's much better. (Hopefully that's what it is, if not then there's more work to do.) |
|
Its not just a windows issue, on mac Gtk makes the REPL also slower. But that is a different issue, which we actually have another thread for. Will give nightly a try soon. Your blog post of course has been read twice, because I was not sure if I was dreaming what I was reading ;-) |
|
@jonathanBieler: Do you have some idea how we could test the implication of this PR? |
|
The optimization level changes what LLVM passes are run. The ones at O2 tend to be those that are useful on inner loops like loop unrolling, different type of vectorizations etc. I don't think there will be a measurable runtime performance for a warpper libarary like this. |
|
Sounds good to me, but I can test on GtkIDE tomorrow, it's a pretty large app so if something horrible is going on I should be able to feel the difference in responsiveness. Only issue is that it crashes pretty fast on v1.5 xD |
|
I can't really notice any difference, e.g. interactive plots with Immerse are still pretty snappy (after the initial compilation lag). |
This, together with the same change in GtkReactive and ProfileView, shaves about 200ms off the first call to ProfileView.view(). Not bad, but not a game-changer either.
xref JuliaLang/julia#32705 (comment)