Erlang Efficiency quesitons

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Erlang Efficiency quesitons

James Hague-3
> > These days with the rise of XML, efficient string support
> will become
> > much more critical.
> >
>
> Yup,

Eight bytes per character bugs me as much as anyone, but in all honesty is
string processing in Erlang really blindingly slow compared to other
languages? For simple filters, Perl walks all over Erlang, but for parsing
and such I'm not sure. Even if Erlang is a bit below average in the string
processing department, the performance of the rest of the language is better
than any interpreted language I have used. Heck, even in toy benchmarks it
walks all over some compiled Lisps.  And as it stands, Erlang doesn't
involve issues about 8 vs 16 bit characters.

It would be trivial to justuse  binaries instead of strings as it is, I
think.  I rewrote a custom lexer to use binaries instead of lists, and it
ended up much cleaner.

James


Reply | Threaded
Open this post in threaded view
|

Erlang Efficiency quesitons

Chris Pressey
James Hague wrote:
> Eight bytes per character bugs me as much as anyone, but in all honesty is
> string processing in Erlang really blindingly slow compared to other
> languages? For simple filters, Perl walks all over Erlang, but for parsing
> and such I'm not sure.

Since Perl is (presumably!) optimized for text-handling, comparing
Erlang against it probably isn't a fair or realistic comparison.
Compared instead to a language with less emphasis on
string-manipulation, for example Visual Basic perhaps, Erlang's string
performance seems perfectly adequate.  (i.e. VB strings are just as
slow, or were the last time I used VB anyway.)

> Even if Erlang is a bit below average in the string
> processing department, the performance of the rest of the language is better
> than any interpreted language I have used. Heck, even in toy benchmarks it
> walks all over some compiled Lisps.

In my experience, raw speed is not as important as the "perception of
timeliness".  Erlang might have some points against it speed-wise (I've
found it's really easy to accidentally write O(N^2) or slower
algorithms,) but it has a huge point for it with regards to how fast it
*seems* to go.  The lightweight processes and fair dispatching give the
impression of smooth, almost continuous operation.  Compared to programs
written in Perl and even C++ which can seem to run choppily.  For many
people, choppy operation is more disconcerting than slow operation, all
other things being equal (hey, you can always get a faster computer...)

> It would be trivial to justuse  binaries instead of strings as it is, I
> think.  I rewrote a custom lexer to use binaries instead of lists, and it
> ended up much cleaner.

I like some of the ramifications of optimizing strings.  For example
Erlang programs would compile a bit quicker (unless I'm profoundly
mistaken about how the compiler works.)

_chris

--
"Ten short days ago all I could look forward to was a dead-end job as a
engineer.  Now I have a promising future and make really big Zorkmids."
Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/
Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html


Reply | Threaded
Open this post in threaded view
|

Erlang Efficiency quesitons

Björn Gustavsson-3
Chris Pressey <cpressey> writes:
> I like some of the ramifications of optimizing strings.  For example
> Erlang programs would compile a bit quicker (unless I'm profoundly
> mistaken about how the compiler works.)

I doubt that. Strings are not used much inside the compiler. Tuples,
records, and lists are. Strings are only used a lot in the parser pass.

$ /usr/bin/time erlc +time erl_parse.erl
 error_if_jam                  :      0.000 s (5240 k)
 remove_file                   :      0.000 s (5240 k)
 parse_module                  :      1.430 s (23040 k)
 transform_module              :      0.000 s (23040 k)
 lint_module                   :      0.530 s (23040 k)
 expand_module                 :      0.210 s (23040 k)
 v3_core                       :      0.380 s (23040 k)
 v3_core_opt                   :      0.980 s (23040 k)
 v3_kernel                     :      1.050 s (23040 k)
 v3_life                       :      0.440 s (27040 k)
 v3_codegen                    :      0.800 s (27040 k)
 beam_block                    :      0.340 s (27040 k)
 beam_bs                       :      0.030 s (27040 k)
 beam_jump                     :      0.140 s (27040 k)
 beam_type                     :      0.090 s (27040 k)
 beam_flatten                  :      0.030 s (27040 k)
 beam_asm                      :      0.260 s (27040 k)
 save_binary                   :      0.000 s (27040 k)

real       16.9
user        7.3
sys         1.1

As you can see, the parse_module pass consumes only a relatively
small proportion of the compilation time.

/Bjorn

--
Bj?rn Gustavsson            Ericsson Utvecklings AB
bjorn      ?T2/UAB/F/P
                            BOX 1505
+46 8 727 56 87    125 25 ?lvsj?