I was finishing up one of my applications last month, which is an accounting app, and while testing, I noticed that there was an atrocious Work-unit cost for creating a single invoice with several items.
Optimizing the process for reduced WUs was an experience but I managed to reduce the work units by a large margin, and learned some things in the process.
So, I created a video and wrote an article to share them with the community here!
I’d love to hear you guys’ thoughts! I’m open to constructive criticism as I’m still learning and it’s possible that I have made some mistakes too. Always happy to share and learn more from you guys!
Could you share some numbers of WU consumed with this conditional versus the other approach…from my understanding that conditional is not a search but is referencing data that is already on the page (ie: already fetched from server and already stored in the repeating group) and is just taking the sum of the existing data on the page and so therefore should not be a new search performed.
In your testing does a database trigger change incur these costs below…if it is to run, then charged the running of a server side workflow action…then just to verify the conditional isn’t there a database search taking place that would return a single result (being the thing that was changed) and also returns all the characters associated with all the data fields of that thing that is changed and then also incurring a charge for each data trigger workflow initiated?
With the slide below, have you compared the difference with the new schedule api workflow on a list as it has been updated and Bubble has expressed that it saves considerably as compared to the cost of recursive workflows?
Hi @boston85719 , really appreciate your input on this matter.
I should have posted the exact numbers with the post but I’d already made massive changes in the application and unfortunately didn’t have the wisdom to record those numbers back when I was optimizing, I’m trying to re-create the environment again so I can make a quantitative comparison which is definitely what a discussion like this deserves. I’ll be posting those soon but allow me to make some clarifications on your questions before that.
The context to this change was that I had a repeating group with some text headings like “Discount %”, “Tax %”. The conditions were such as “Discount % only displays when the total sum of discounts in the repeating group > 0”, same for headings. You’re absolutely correct in saying that Bubble shouldn’t be searching them again, I think it was likely the aggregate function that was racking up WUs (I remember it being 0.2 WU for each condition). Again, not that much individually, but if you have multiple conditionals on one page, I would prefer to not have those WU costs at all.
Yup, you’re right about that. The cost of checking the conditional will always be an extra WU cost thats incurred. This is exactly what Petter Amlie says in his article here (Which I need to add credits to - I learned a lot from this article): Database Trigger Events And Workload | In-depth Bubble Guide
He also adds that DB triggers shouldn’t be engineered in a way that their conditions will be checked on many occasions where they’re never needed to run, which is super important.
Yup, I believe there’s a really minor but hidden cost associated with checking those.
I did try that out, yes, but didn’t see a difference in WUs. I could have done something wrong or made an error in checking so I’ll definitely check this out again and report back to you with my findings, thank you for bringing this up.
Thank you for the opportunity to discuss this with you!
There should be no hidden costs whatsoever in Bubble for WUs…not saying you are incorrect, but saying Bubble should be publishing this along with all other actions/events/conditions etc. that incur WUs.
Thanks for sharing your findings. I have not taken any time personally to do any sort of deep dive onto WU consumption and comparing different approaches, so very interesting to see what others have found.
I’ll have to read that article, thanks for sharing the link.
UPDATE
Just read that article. Some good stuff in it…I am highly curious though as to how we could simplify the condition as expressed is possible in the article
Seems to me like that condition is as simplistic as possible so as to get the trigger to run only when necessary, but I’d love to hear others thoughts on how to get the same functionality but with a more simplistic expression that does not require the field to be counted twice.
