What’s the best (fastest) way to determine if a list is empty - checking if “count = 0” or if “:first item is empty”? Is there another way?
I initially thought the list itself could be checked if empty since the “is empty” operator is available, but apparently that can’t be done.
Check out this response from @keith here: Is "first item is not empty" faster than "count > 0"?
Thanks, @romanmg! Don’t know how I missed that during my search. 
Thanks @romanmg for finding my response to that other question. @sudsy: Please note: the question posed at Is "first item is not empty" faster than "count > 0"? is different than the one you post above.
Your question here asks about two list conditions that WOULD NEVER interrupt a Search (regardless of whether Bubble does that optimization or not). A list can only be evaluated for first item’s emptiness when the list is fully constructed. Similarly, we can only evaluate that a list’s length is 0 after the list is fully constructed.
Both depend on the list being fully constructed to evaluate. But there are conditions that do give a reason to stop a Search in progress. Both of the following conditions are candidates for that (and these are the ones asked about in the older post:
Which is faster?: some_lists's:first item **is not empty** or some_lists's:**count > 0**… where both lists are constructed via a Search. (Let’s call these conditions C and D.)
I stand by my answer to the original question. I think that what :count represents in Bubble is “get the length of a list like a function”. The irony is that, internally, lists always have a .length property (as we can discover when we start working with actions in the plugin builder (especially server-side actions).
So :count > 0 is a condition that actually could be “looked ahead”. (“length” isn’t a function there, it’s a property)
Most folks get that C (first item is not empty) provides a good reason to stop a Search while in progress. In the first case: The condition logically becomes true as soon as the list has 1 item in it. As soon as there is even 1 item, Bubble could stop searching (but does it? I think it does).
Expression D (:count > 0) is less obvious. Because Bubble calls this property “count”, a lot of folks take that to be a verb. Mentally they think, oh well you can only “count” the number of things after we have all the things. (And, if :count means “grab the lists length like a function” then this is correct thinking.)
Ironically, internally, if you have a list (an object like properties.theList) and you want to know: “is that list empty?”, the way you do that is check for properties.theList.length < 1 or properties.theList.length = 0. You do not need to have the values in the list to know that fact. (And, to retrieve the values in the list, you have to do a function call to the list’s .get() function. So, you’d never go about determining a lists’s emptiness by sorting it and then looking at the emptiness of its first element!
(What I’m saying above is: Some of the things you would do when designing an algorithm in Bubble editor are, in fact, the exact opposite of how you would do things in JavaScript/node when working with Bubble internals.)
Thanks, @keith, for the thorough explanation!
When all one wants to do is simply determine if a “list is empty”, having to reference either “count” or “first item” seems like it should be unnecessary. In fact, I initially assumed it would work given that “is empty” is available for the list when constructing the condition, so I was baffled when Bubble refused to turn the text blue in agreement! 
Were it possible, though, I would assume that “under the hood” Bubble would use the most efficient means possible to check for “emptiness”.
Anyway, I guess I’ll go with “first item”, but it would be more terse, more intuitive, and less visual clutter to simply say if “theList is empty”.
Please note, in case it’s not obvious from my comments. Do NOT evaluate “:first item is empty”. This way is not maximally performant. You want to get used to evaluating whether a Search returned any objects like this:
Do a search for... (some thing with some constraints):first item **is not empty**
If this is yes, the Search returned items (the list is “not empty” as you would have it). if this is no, the Search returned no items (the list “is empty” as you would have it).
Phrasing the Search and the condition this way minimizes the time it takes to evaluate this state.
As for why Lists in this context have no empty condition, I have a lot to say about that, but I haven’t phrased it the right way yet. Stay tuned, i guess.
Ok, so you’re basically saying to invert the logic. You’re right; I didn’t pick that up initially. Thanks for clarifying.
