-
compilation
To compile your code the IDE needs to “walk” through all the items and send the text of each items to the compiler
Workers cant be used in their current form to walk through the project because you can only send a worker TEXT - which means in order to send it to a worker it has to already be converted to text - so a worker isn’t useful
However, once all the items in the project have been converted to text that can be compiled the compiler can convert that text into machine code and do some local optimizations on it. (Loop unrolling is a local optimization)
You may see several processes start up to do this.Once all these items have been converted to machine code (object code) they have to all be “linked” This means resolving various addresses the ENTIRE compiled binary - which you canto do properly until you put all the parts together.
So multiple processes don’t necessarily help here.
As well Xojo happens to do global optimizations at this point - because it has all the code at one time in one place so it can do work to strip things out that are unused, etc
-
debugging web projects - each session on a core
not a bad idea BUT probably requires a framework that is thread safe so you can have several running as independent threads without clobbering each other.
Xojo’s frameworks aren’t and it is a significant undertaking to make them be so -
loading plugins - you could sort of use a worker but it wouldn’t make thing a ton faster
When the IDE loads a plugin it literally examines it and creates an API IN Xojo code for it so the functions can be seen by autocomplete etc. Its much like a person writing a dylib then manually writing a pile of declares into that dylib to expose the API. Its just done automatically by the IDE.
And each item generated by this is a class instance that represents that plugin
Since you cant pass classes or anything other than text from a worker a worker doesnt help that much.
A worker would read the plugin, do the API generation, have to then turn that into text to pass back to the main IDE thread, which then has to take that text & turn it back into an instance of the class used to represent the API to the plugin