Is even 2x speedup helpful for your purpose? 3 seconds is one old magic
number for user patience in HCI, so I suppose there's still a big
difference between 4 seconds and almost 10 seconds?
For large (and absolutely massive) XML... SSAX can shine even better
than in this comparison, since you can, say, populate a database *while
you're parsing, without first constructing the intermediate
representation* of xexpr or SXML. GC-wise, with the database-populating
scenario, you'll probably end up with small, little-referencing, local,
short-lived allocations. Besides GC costs, you'll also use less RAM
(possibly lower AWS bill), and be less likely to push into swap (which
would be bad for performance).
In addition to SSAX's current performance characteristics and
opportunities... There might also be opportunity to optimize SSAX
significantly for Racket. Oleg is a famously capable Scheme programmer,
but he was writing SSAX in fairly portable Scheme code, a couple decades
ago, when he wrote SSAX. I did an initial packaging of SSAX for PLT
Scheme, Kirill Lisovsky later did many packagings of various SXML-ish
tools (including his own), and then John Clements did more work to
package Oleg's SXML-ish tools for Racket... But I don't know that anyone
has had motivation to try to optimize Racket's SSAX port, using current
Racket features, and tuning for current performance characteristics.
Side note regarding performance comparison... FWIW, SSAX might be doing
some things `read-xml` doesn't, such as namespace resolution, entity
reference resolution, and some validation.
--
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 racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/racket-users/828c5a26-0dec-a1d6-5ca3-04376113bf6c%40neilvandyke.org.
