This is just to short-circuit a function, so I'm looking for the thing that will do the least amount of work possible. Sounds like seq.

I believe that many Clojure programmers consider (seq coll) as idiomatic for this purpose.

it's the recommended idiom for testing non-emptiness on any collection, yes

for counted collections, (zero? (count coll)) should be faster (`seq` will allocate an object if non-empty)

seq basically just returns an iterator though doesn't it? it doesn't do anything besides that, like attempting to convert the sequence

Which collections are counted?

seq wraps the collection in a lazy sequence if not already one. If you call it on e.g a vector, it will coerce it and create a sequence. It's cheap, but not totally free.

@U06B8J0AJ eager collections are counted

some lazy seqs are counted as well but I would not rely on that

(zero? (count …)) appears to be faster for counted collections indeed. Edit: Actually, rereading the numbers, using seq is better than a conditional check. Therfore, (zero? (count …)) only when it's certain to be a counted collection.

This is for a fairly large collection of about 200k items.

BTW counted? exists

How did you measure that?

@U06BE1L6T (criterium/bench …) https://github.com/hugoduncan/criterium/

this may be relevant (including survey data) https://clojure.org/news/2019/02/04/state-of-clojure-2019

cool thanks

how did you build a-list ?

Cool! Doesn't really help in situations where seq is idiomatic though.

yo? seems slightly more efficient than bounded-count.

Parsing XML. I use it to halt evaluation early when a previous step in the parser produces no data of interest. In practice it does make a difference in performance, and choosing the right way to evaluate whether data is present or not seems to make an additional difference.

But also, it's just fun to learn the performance implications of the different alternatives. I didn't initially expect this line of investigation to yield much of interest.

what is the type of the thing being returned that you are checking?

The XML documents are in JATS format which is a right mess of data-meant-to-be-read-as-metadata, data-meant-for-display, and data-meant-to-simultaneously-work-for-display-and-metadata. My solution (which is probably suboptimal to begin with, but nevertheless) essentially invokes different parsers for different branches, that might return more data to be processed by a different parser and so on (because a "display" section, which I turn into hiccup, might return some forms that also needs to be read into proper named fields and so on). As a side effect of this solution, parsers return a collection that might or might not be empty. To avoid looking for another parser for nothing, I kill the branch at that point.

well, in general, it's better to avoid making the empty collection in the first place if you can avoid it

that's why clojure collection functions are polymorphic on nil

Consistently return nil and use nil?

conj, assoc, etc

you don't need nil?, you can just use the value itself as a logical value

which is either nil or not

(if (parse ...) branch-when-parsed branch-when-nothing)

Before (parse …) there's a lookup to find the correct parser, which reside in a map currently. I'm guessing that's the bottleneck that I'm circumventing.

Invoking ((get {…} nil) data), which resolves to (nil data) isn't great, so at some point I have to shut things down before it gets to that.

And it seems to be more performant to shut it down before (get …) than on receiving nil from the index.

why would you not find a parser?

could you return a default "not-found" parser that did the right thing?

((get parser-table nil not-found-parser) data)

make the special case not special

Yeah, true, I could do that. not-found-parser would return nil no matter what. Do you reckon that would be better than checking for emptiness?

yes

Alright, I'll give it a shot!

this is all general advice applicable in many places... don't make empty collections, lean on polymorphic collection append functions, use identity/nil as a predicate, etc

seq is a good predicate when doing seq things. you're not doing seq things.

the code above will be smaller, more readable, and more performant

I'll try it out and measure. Thank you. I haven't internalised the nil case into my collection of idioms like this. It's a good a time as any.

To report back, I'm not measuring any significant performance difference, but it did get rid of a conditional which is nice. In practice, I inject an mapping of nil to (constantly nil) in whatever handlers is passed to the function. No API change visible outwards, and overall it seems like a cleaner solution.

If you don’t have JavaFX or are more familiar with Swing, seesaw remains quite useful. It’s the basis of my most-used project: https://github.com/Deep-Symmetry/beat-link-trigger#beat-link-trigger

This small project was announced just recently, using Seesaw and Clojure: https://www.reddit.com/r/Clojure/comments/bx698b/i_made_a_small_epub_reader_in_clojure

@U07FND2KH @U051SS2EU @valtteri @UHL84CDTP The Clojure ecosystem now has a reliable & versatile background processing & scheduling library: https://github.com/nilenso/goose

If you have a need for it, do give it a spin and ping in #goose for any issues or feature requests.