use Perl

• It may be obvious, but... (Score:1)

  by godoy (2167)

  Matt, it may be obvious, but have you compared the algorithms used at xmllint and your Pure Perl parser?
  
  C allows some optimizations where Perl allow them to occur in other places.

  --
  -- Godoy.
  • Re:It may be obvious, but... (Score:3, Interesting)

    by Matts (1087)

    The problem is that Perl is just slow. Not really much I can do about that. When you compare it to C, where it can do really nice things like char = ++*p to get the current character and move to the next byte in a string . With perl a similar idiom is: $char = substr($str, 0, 1, ''), which has a lot more overhead (same for a regexp to do the same). Character-wise coding in perl has always been a bit of a pain.
    • Re:It may be obvious, but... (Score:2, Interesting)

      by jdavidb (1361) on 2002.02.04 13:05 (#4059) Homepage Journal

      Maybe someone needs to write a character-array manipulation class, a la PDL for huge matrix crunching. The class would gain a lot in efficiency for trading away the many capabilities Perl ordinarily gives. This would be something gross in XS, I'm sure.

      Or maybe, if I'm thinking of writing a custom text-manipulation class for Perl, something's dreadfully wrong with the world. In much the same way that we always took XML::Parser's dependence on a C parser as an indication that something was wrong (and we were right).

      Remember the C<less> pragma? You could supposedly use less 'memory' or whatever, and the interpreter would switch optimizations around to trade speed or whatever for memory. It'd be cool if you could trade off abilities on a scalar for efficiency. As in, declare that this scalar can never be bound to a regex operator such as m// or s///.

      What am I rambling about?

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers

      Reply to This

      Parent