@MonkeybreadSoftware
(Speed up compiler by caching text representation of project items for use in multiple targets - #5 by Christian_Schmitz - General - Xojo Programming Forum)
Yes, no idea how often this happens and whether items could be marked to not be cached. But if 90% could be cached, it may help.
Compatibility flags need to be examined for each project item to know if it should be rendered for whatever target is being built. More so than just about anything else to know if an item is/is not part of the target being built.
You could possibly cache those items that are marked as compatible with every project type
Others would need to be re-examined
You examine the flags before you start rendering the text, so before the cache is considered.
So you can cache it for macOS targets and skip the cache for Windows if the item is not included on Windows.
That is what I said above
Yes - some text could be cached as the IDE doesnt do code stripping in #if etc
The compiler does that
They could probably just cache text and reuse it when / if it IS compatible
And if not then re-render just like they do now
Much smaller change
Well, the whole thing started by me looking on the build dialog. I saw my own classes going by several times, so I wondered wether the IDE does the same work twice or more often.
I’d welcome if something could be optimized and cut out a few percent of every build.
No idea wether it can be done and is worth the investment.
It just does in an order that is different than you might expect and it may save a little time
Plugins it might NOT be able to cache the text since a plugin, like anything else, can have functions that are exposed on on target and not another
Don’t recall if it turned those into compat flags that can be easily examined
I’m sure there’s something that could be done but seriously they have enough bugs to fix , Android, web 2 etc
super low priority as far as I’m concerned
1 Like
As I mentioned on TOF, another problem is the actual rendering process. There’s a lot of code that is created for each target that is conditional on the target itself. So even within the realm of “Windows”, the rendered code could be different between 32-bit, 64-bit and ARM. Last I knew, there was no way to easily “know” that a code item was going to render differently for any particular platform-cpu combination.
1 Like