.length vs. count for string length

2,612 views
Skip to first unread message

Alice

unread,
Oct 30, 2013, 6:44:47 AM10/30/13
to clo...@googlegroups.com
Which one is preferred?

.length needs to be type hinted, so more verbose.
The performance penalty of count is negligible in most cases.

I think including len in clojure.string would be a good idea because it's used so often.

Baishampayan Ghose

unread,
Oct 30, 2013, 6:50:04 AM10/30/13
to Clojure Group
What'd clojure.string/len do any differently than clojure.core/count?
count already provides does the fastest possible thing for strings.
~BG
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Baishampayan Ghose
b.ghose at gmail.com

Alice

unread,
Oct 30, 2013, 7:53:33 AM10/30/13
to clo...@googlegroups.com
count does some type checks, but it's negligible in most cases as I already said. len can give a clear intention than count somtimes.

I'm not suggesting that it should be included in clojure.string, but if count is currently not preferred over .length, including it can be a good option.

Luc Prefontaine

unread,
Oct 30, 2013, 9:23:45 AM10/30/13
to clo...@googlegroups.com
Strings are character sequences, count is a better option to stay
within the sequence abstraction.

Lic P.


> count does some type checks, but it's negligible in most cases as I already
> said. len can give a clear intention than count somtimes.
>
> I'm not suggesting that it should be included in clojure.string, but if
> count is currently not preferred over .length, including it can be a good
> option.
>
>
> On Wednesday, October 30, 2013 7:50:04 PM UTC+9, Baishampayan Ghose wrote:
> >
> > What'd clojure.string/len do any differently than clojure.core/count?
> > count already provides does the fastest possible thing for strings.
> > ~BG
> >
> > On Wed, Oct 30, 2013 at 4:14 PM, Alice <doff...@gmail.com <javascript:>>
> > wrote:
> > > Which one is preferred?
> > >
> > > .length needs to be type hinted, so more verbose.
> > > The performance penalty of count is negligible in most cases.
> > >
> > > I think including len in clojure.string would be a good idea because
> > it's
> > > used so often.
> > >
> > > --
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > To post to this group, send email to clo...@googlegroups.com<javascript:>
> > > Note that posts from new members are moderated - please be patient with
> > your
> > > first post.
> > > To unsubscribe from this group, send email to
> > > clojure+u...@googlegroups.com <javascript:>
> > > 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+u...@googlegroups.com <javascript:>.
> > > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
> >
> > --
> > Baishampayan Ghose
> > b.ghose at gmail.com
> >
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
Luc Prefontaine<lprefo...@softaddicts.ca> sent by ibisMail!

Luc Prefontaine

unread,
Oct 31, 2013, 11:22:47 PM10/31/13
to clo...@googlegroups.com
I meant collection ... not sequence.

Luc P.

Mikera

unread,
Oct 31, 2013, 11:37:33 PM10/31/13
to clo...@googlegroups.com
On Wednesday, 30 October 2013 18:44:47 UTC+8, Alice wrote:
Which one is preferred?

.length needs to be type hinted, so more verbose.
The performance penalty of count is negligible in most cases.

Doing a quick micro-benchmark with criterium I get:
- .length at 5.5 ns
- count at 50.0 ns

i.e. both are very fast, but .length has a significant advantage if you are calling it a lot in performance-sensitive code.

OTOH, count is much more generic since it can handle arbitrary sequences etc. Also count doesn't require type hints. You should definitely prefer count when writing most high level code.

vra...@gmail.com

unread,
Nov 1, 2013, 12:38:36 PM11/1/13
to clo...@googlegroups.com


On Thursday, October 31, 2013 10:37:33 PM UTC-5, Mikera wrote:
OTOH, count is much more generic since it can handle arbitrary sequences etc. Also count doesn't require type hints. You should definitely prefer count when writing most high level code.

Yes, I'd prefer count in higher level code over .length for easier Clojure / ClojureScript code sharing.

For what it's worth, src/clj/clojure/string.clj uses `.length` throughout (except the capitalize function for I don't know why).

Sean Corfield

unread,
Nov 1, 2013, 2:40:42 PM11/1/13
to clo...@googlegroups.com
This thread made me run a quick audit of our code and we had about a
dozen calls to .length, a dozen calls to .substring, and a handful of
calls to .replace - of which a few were in truly performance sensitive
code (doing Unicode-related processing across large strings, so they
had lots of other Java interop and type hints, and were deliberately
procedural). Replacing the rest with count, subs, and
clojure.string/replace (renamed to str-replace to avoid
clojure.core/replace) definitely looks "nicer" and runs plenty faster
enough for what we need.

So thanks to Alice for raising this and spurring me to make our code
more idiomatic :)

Sean
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

mattias w

unread,
Apr 10, 2016, 5:53:38 AM4/10/16
to Clojure, seanco...@gmail.com
With clojure 1.8, we got many of these functions, but not str/length and str/substring. 

What am I missing?

/mattias

Sean Corfield

unread,
Apr 10, 2016, 1:44:20 PM4/10/16
to Clojure Mailing List
On 4/10/16, 2:53 AM, "mattias w" <clo...@googlegroups.com on behalf of matt...@gmail.com> wrote:
> With clojure 1.8, we got many of these functions, but not str/length and str/substring.

Because we already have `count` and `subs` in clojure.core

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood





Reply all
Reply to author
Forward
0 new messages