3 ms·
I'd expect a fast json parser to be harder to use than an easy-to-use or simple one. But if I need to eke out maximum performance on something I'm going to ski
by rendaw 6y ago
I'd expect a fast json parser to be harder to use than an easy-to-use or simple one. But if I need to eke out maximum performance on something I'm going to skip the ones that don't have fast in the description - it means the project's goals aren't aligned with my use case. If it's a web project then I'm going to focus on parsers that have have actually considered security over the ones that haven't.
These are all important words for describing projects.
- s3ker 6y agoYou forgot to add military-grade encryption and cloud-native tags
- johnchristopher 6y agoFast is not a KPI though. It can and is often labeled on anything, making the term useless even when fast is a criteria over ease of us. Maybe something at the top along the lines of : what it does, how and then what are the implications.
- mikepurvis 6y agoClaiming "fast" implies that performance is a project goal, possibly even tracked over time as a metric, and that there's probably a comparison deeper in the README or elsewhere. It probably also means that when it comes to tradeoffs (compile time, code size, binary size, ergonomics, maybe even strictness/correctness), runtime speed is the preferred option.
- jeddy3 6y ago"[description], aimed at speed" or something like that is better in that case, IMHO.