Using multiple cores in the IDE

@TomCatchesides @DavidCox

  1. 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

  1. 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

  2. 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


Thanks, Norman. It sounds like there might not be much scope for improving the time it takes to run a debug build by using multiple cores, which is a real shame considering that people using Xcode say that the M1 chips are making their builds so much faster.

There are places where multiple cores can help but its not as frequent as many would hope

1 Like

Workers however, are unlikely to be the means to do it though

1 Like