To me it looks like a leftover from some Clojure pre-history where it made
functional sense.
On Friday, May 19, 2017 at 6:54:32 PM UTC+2, Tianxiang Xiong wrote:
>
> That seems unlikely to be the reason here. ¯\_(ツ)_/¯
>
> As you said, the `null` check should come first if performance is the
> driving concern. Besides, why check for a subinterface *and* its
> superinterface only for this case? There are more cases that could be
> checked.
>
> On Friday, May 19, 2017 at 7:09:00 AM UTC-7, Mikera wrote:
>>
>> One of the things that JVMs can do is create a small cache for the most
>> recently seen classes in instanceof checks. I believe both OpenJDK and the
>> Oracle JVM do this.
>>
>> So if you check for both ISeq and Seqable, you may find that you get
>> twice as many classes cached, and therefore see a performance benefit. Of
>> course this is implementation dependant so YMMV.
>>
>> On Friday, 19 May 2017 11:28:27 UTC+8, Tianxiang Xiong wrote:
>>>
>>> But if something is `ISeq`, it's `Seqable`, so checking for `Seqable`
>>> alone should be sufficient.
>>>
>>> Am I missing something here? Is there a performance performance benefit
>>> of checking for `ISeq` *and* `Seqable` that I'm not aware of?
>>>
>>> On Wednesday, May 3, 2017 at 2:19:42 AM UTC-7, Mikera wrote:
>>>>
>>>> Clearly not necessary from a functional perspective.
>>>>
>>>> However I believe the ordering of these tests will affect JVM
>>>> optimisations. You want to test the common/fast cases first. And the JVM
>>>> does some clever things with caching most recently used lookups, which
>>>> will
>>>> again behave differently if you test things in different orders.
>>>>
>>>> Benchmarking on realistic workloads would typically be required to
>>>> determine the optimal order.
>>>>
>>>> FWIW I find it odd that the null check is third. This is extremely fast
>>>> (certainly faster than instance checks) and is a very common case given
>>>> the
>>>> amount of nil usage in idiomatic Clojure code (as an empty seq), so I
>>>> would
>>>> probably put it first.
>>>>
>>>> On Wednesday, 3 May 2017 11:59:29 UTC+8, Tianxiang Xiong wrote:
>>>>>
>>>>> Why does `clojure.lang.RT/canSeq` need to check both `ISeq` _and_
>>>>> `Seqable` when `ISeq <- IPersistentCollection <- Seqable`?
>>>>>
>>>>> static public boolean canSeq(Object coll){
>>>>> return coll instanceof ISeq
>>>>> || coll instanceof Seqable
>>>>> || coll == null
>>>>> || coll instanceof Iterable
>>>>> || coll.getClass().isArray()
>>>>> || coll instanceof CharSequence
>>>>> || coll instanceof Map;
>>>>> }
>>>>>
>>>>>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
