<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>Here are the results from Windows 10 (run from inside Virtualbox):</p>
<p><img src="cid:5cc725b5ebd1858abc070bd2232d0ab8@carto.net" /></p>
<p id="reply-intro">On 2020-06-10 11:50, Nyall Dawson wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">On Wed, 10 Jun 2020 at 19:37, Andreas Neumann <<a href="mailto:a.neumann@carto.net">a.neumann@carto.net</a>> wrote:
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><br />Hi Nyall,<br /><br />You are right. GRASS and SAGA take the longest time in initialization. Perhaps we should disable those by default. I think both are for advanced users. These users should know how to enable the SAGA and GRASS providers, should they need them.<br /><br />Here is the screenshot from my QGIS on Linux (without SAGA) (I'll send another one for Windows later):</blockquote>
<br />Thanks! I'm going to add some more granularity to the GRASS startup<br />login shortly (but I'm 99% certain it will confirm that the issue is<br />the text file reading...)<br /><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><br />Seems like DataPlotly also takes substantial time to load.</blockquote>
<br />Yes - unfortunately that's the 3rd party plotly imports themselves<br />which are slow. Possibly there's a way to defer these imports until<br />needed till. Could you file an issue on the DataPlotly tracker about<br />this?<br /><br />Nyall<br /><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><br />Greetings,<br /><br />Andreas<br /><br /><br />On 2020-06-10 11:27, Nyall Dawson wrote:<br /><br />On Wed, 10 Jun 2020 at 19:22, Andreas Neumann <<a href="mailto:a.neumann@carto.net">a.neumann@carto.net</a>> wrote:<br /><br /><br />Hi,<br /><br />Given that the initialization of the Processing plugin takes around 2/3 of the QGIS startup time, I wonder if we can discuss how to improve the situation?<br /><br />Can there be a "delayed" or "on demand" loading of processing if the user needs it?<br /><br />Quite a lot of users use QGIS for viewing or editing, without any need for analysis. I know that they could disable the processing plugin or use a different user profile where the plugin is disabled, but ...<br /><br />Is there something that we could do as QGIS developers to speed up, delay or on-demand load the processing plugin?<br /><br /><br />Yes, I think there's lots we could do. But I'd love to see a<br />screenshot of the new startup time profiler for one of your affected<br />slow-to-start machines.<br /><br />Typically the culprit is the GRASS and SAGA providers, where they load<br />algorithms from 100s of text files. File access like this on Windows<br />is very slow, so I think the easiest thing to try first would be if we<br />concatenate all the definitions into a single master text file...<br /><br />Nyall<br /><br /><br />Thanks for the discussion,<br /><br />Andreas<br /><br />_______________________________________________<br />QGIS-Developer mailing list<br /><a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br />List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br />Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br /><br /><br /></blockquote>
</div>
</blockquote>
<p><br /></p>
</body></html>