I have not come across an example of this yet. Do any obvious cases come to mind where we as the developer are in control of the choice?
I don’t know why this would be possible as moving away from capacity to WU was meant to allow Bubble to charge based on computer power usage which tied into server usage which if something takes less time to process on the server it costs less in terms of WUs. Unless the idea of polar opposites is not implying they are inversely proportional as in this example where the performance improvement is not a 1:1 relation to the extra WU costs incurred.
I suppose that is true if we only focus on the idea that requesting two different searches from the server at the very beginning of the workflow series triggering makes it so that when the series reaches the one action with the formatted as text conditional evaluation taking place it is already available and so when the time that one action is executed and the condition evaluated is the only way to do something.
I tend to put faith in the idea that the moment the trigger takes place to start the workflow series, if that condition is evaluated at that moment and immediately there after requests from the server the one search necessary, that would be a more performant way to do things overall as there is less stress on the servers, which in my mind should be Bubbles goal and so confuses me why they would choose a negligible performance improvement (especially as they could have if intentionally focusing on such a decision, decided to just evaluate the condition immediately) over reducing overall strain on server, database I/O and resources overall (doesn’t bubble pay their suppliers for usage as well?)
So, yes, as it is something forced upon as as Bubble made that arbitrary decision, it is thought to have been made intentionally with the idea that the slightest increase in performance is preferred by the User (ie: app owner/paying bubble customer) and the extra costs incurred of WUs (paid for by the customer to Bubble) is negligible for the improved performance…which I’m not sure a conditional evaluation would take much more than some number of milliseconds.
Plus I don’t know if the size of the searches is something that is taken into consideration here, where yes, a small sized search might have the performance bonus at the expense of extra costs, but if the searches are large and take time to fetch, I don’t think the perceived improvement to fetch both first rather than evaluate first (again, I believe the only real difference here is order of operations since if we search twice first, the searches are cached, but the condition still needs to be evaluated on the client which would have the same amount of time required to be evaluated if the condition were evaluated first - meaning time to evaluate condition = 0.1ms and time to fetch = 1.5ms; doesn’t 'time to evaluate + time to fetch = time to fetch + time to evaluate).
I think ultimately if, the decision was intentional and a perceived performance improvement is had by running both searches first, it was maybe made with an assumption that ‘all searches are equal’. So, let’s say my Yes evaluation is for a search I expect will return 10 results, but my No evaluation is a search that may return 1,000 results. Would it not be more performant to evaluate first and return the 10 results? I just don’t see this as intentional for performance improvement. I believe it is an oversight, and will not be addressed since Bubble profits from it.
In this situation yes for sure. There should just be the simple checkbox to choose which approach to take, since as the developer, we likely will already know which searches are so heavy that the performance improvement is negligible at best.