As you can probably tell, I’m just assigning the value of the result to a label (using newline as a separator).
tl;dr: I had no idea that I was slowing down my project by a factor of 10-20 times by using cloud variables to access Firebase. I’m going to switch over to Realtime DB Get calls (and maybe Save calls, too) and see how much faster I can make everything.
Fascinating. I was so surprised by your results that I had to replicate. (I also noticed you weren’t doing exactly the same tree depth, and wondered if it mattered.) 50 properties = 5 seconds on my phone.
I think the DB get block is running asynchronously, while the cloud variables are synchronous. It’s hard to time something asynchronous, but definitely under a second, best guess ~400ms.
It definitely wasn’t a scientific experiment but I thought it was noteworthy nonetheless and hoped other people would either disprove it or duplicate it.
I’m still doing tests. Replacing the cloud variable blocks in my photo journal project sped things up a tiny bit but not as much as I had hoped.
I think the issue with cloud variables isn’t fundamentally that they’re slower, but that they run synchronously, so you wait for 50 database retrievals to go one at a time. You can get around that by using the old DB Get block (since it’ll do 50 retrievals asynchronously, which means all at once), or by doing one larger object retrieval (using either method - the difference is probably not significant at this level of testing).
Moral of the story: (until @muneer comes along and proves us both wrong)
If you’re getting the value of one node from the database, it doesn’t matter.
If you’re getting the value of a whole lot of nodes from the database, looping over cloud variables is slow. Get the parent node and parse it with object blocks OR use the Firebase get block to get a whole bunch of values asynchronously.
I bet this is slow because you’re getting the entire top level variable on each loop. If you set a local variable once right before the loop (to cloud variable /app variable top level), I’m guessing it speeds up to something pretty competitive?
I’ll check that. Also, your idea to grab the whole data set and parse it using object blocks is something I was working on.
But I got sidetracked trying to get the new node[index].property text strings to work instead of the old nested property of object blocks. The ones here:
So it really is the cloud variables that are causing all the slowdowns. And yes, thank you for pointing out the synchronous nature of them that’s really the issue.
Firebase works as both BaaS and FaaS which also means in every test you performyou have to cater for the latency introduced by cold start nature of the service. The published timeframe from different test goes up to 6s to get the value of the key in Firestore but takes less in RealtimeDB. Firebase goes into cold start anytime between couple of minutes to over 10 minutes and it seems to respond differently to different coding languages.
So, one way of eliminating such factor is to start with a dummy call first and once you receive the value start your timed test to be sure that all test have nearly similar/controlled environmental condition.
I must say that the cloud variables are easy and straight forward they lack error handling. I cannot use the cloud variables if I want to capture the error to verify if the user is permitted to use this bucket or not. This is one of the issues.
I know this is not a contribution to the retrieval speed test but I just wanted to write anything in this post.
I know you’re always ahead of things @catsarisky and a very quick code writer too. Sometimes, it seems to me you have already dreamt about the issue and know the solution and just responding to the post that was written after you woke up from your dream.
In the subject of speed test.
Firestore is a more stable solution than Realtime DB and most of the articles are comparing Firestore to AWS not Realtime DB and therefore, these is not enough material to compare.
I’ve got everything optimized now. I big change was to get the Firebase top node (“top level”) once (thanks, @catsarisky!) and then use that app variable over and over again in my code:
Now I’m up against the time that it takes to get a photo url from Firebase (included in the top node variable above) and convert it to a smaller size & quality with a customized Cloudinary url:
It’s planned work but feel free to it on GitHub if you agree.
That would allow my users to take a photo and then upload it as a smaller file size → which would speed up the app considerably, especially when adding a new Photo Journal entry.
Yes, I agree with you @tatiang I had this tip in the post of top Thunking tips too. Use the cloud variable to get the data from your DB and then manipulate the data using app variables.
Well… I think it’s primarily the upload. But I just like to grumble about it so it gives more weight to the issue if I say it affects both.
In all honesty, it’s a guess but I think it does affect the download as well. Thunkable is storing a full-quality full-size image from my phone (~10 MB) and then having to convert it to a fraction of that for downloading and displaying in my app. It’s entirely possible that Cloudinary takes the same amount of time to convert a full-size image as it does to convert a resized smaller image… I just haven’t tested that.
Not a bad idea but the delay is significant. It takes 5-12 seconds to upload a photo from my phone to Cloudinary and get back a mediaURL. That seems to be the going rate. That seems unusable for anyone except me. I can’t imagine another user just being okay with that kind of delay. So I have to figure out some way to distract the user during that time.
I’m building the app with several screens… if it was all one screen, the delay wouldn’t necessarily matter. But the journal entry screen just allows for a photo and description to be added before saving to Firebase. And if a user skips entering a description, they’d just be waiting as long as 12 seconds for that upload to occur.
Since making changes to my slideshow screen, it now loads 25 entries in 3.5 seconds. Each entry has a small photo and three labels that get populated from Firebase.
And… whoa… 3.4 seconds without the photos.
And… uh… 3.2 seconds to retrieve only the top level node without getting data from any of the properties within it.
This section outlined in black is what takes about 3 full seconds to run:
And if I remove the “if” block and just run that “set” block, it only take 0.3 seconds. So I’m trying to wrap my mind around why checking to see if an app variable is less than a stored variable (both integers) takes 3 seconds.
Sorry for all the thinking out loud in these last few posts but I managed to get the slideshow down to 2 seconds by removing that “if” block and restoring the photo+label data retrieval blocks.
I was not wrong.
it on 