Your code is very string-ops-heavy, and I would start looking at that.
One thing you could do is look for opportunities to construct fewer
intermediate strings, including across multiple procedure calls. You
could also look for operations that are expensive, and use
less-expensive ones. If your strings have no multibyte characters, it'd
be easier to make it a lot faster with reused bytes I/O buffers and a
tons less copying, but you could also try that with multibyte characters
(it's harder and slower, though).
If you get fancy with the optimization, you might end up with a DSL or
mini-language for the formats and/or transformation, to simplify the
source code while making its behavior more sophisticated. But maybe you
want to focus on a proof-of-concept for the optimizations first, before
you go to the work of implementing the DSL.
BTW, the below comment, from an aborted response to your previous email,
doesn't seem to apply to your code, but I'll just note it for the record:
Without tracing through the actual code being profiled (not
volunteering!), it's hard to say what the fix is.
One little tip, from glancing at "collects/racket/string.rkt"... If
your code happens to be calling `string-trim` with a large number of
different `sep` arguments (different by `eq?`), it looks like it will
be especially slow. Or if you're calling `string-trim` a huge number
of times with a nonzero number of non-`#f` `sep` arguments, and you're
GCing. (The implementation assembles regular expressions for non-`#f`
`sep` arguments, and caches them in a weak hash with `eq?` test.)
BTW, I wouldn't be surprised if `string-trim` could be made faster for
the normal case of `sep` being `#f`, though the code doesn't look bad
right now. (The majority of code that people write is not very
efficient, and `string-trim` looks better than the norm.) However, it
was written in a generalized way, and I don't know if anyone sat down
and hand-optimized for the `#f` case specifically. Or, it might have
been written a long time ago, and the VM/compiler or strings have
changed quite a bit since then, and so the code could benefit from
re-hand-optimizing. (I've done a bunch of that kind of optimizing as a
consultant, and it can easily take a few hours for a single procedure,
so tends to only happen as-needed.)
Neil V.
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
