8

I found this question and accepted answer on StackOverflow. It's related to the slow JSON parser in the standard Scala library.

The consensus as it were, is that the build-in JSON library is slow, and, in the words of DMC: "it's like that, and that's the way it is"

Maybe I'm just being naive here, but that sounds like a bad approach to grow the language. Shouldn't the built-in libraries be perfect? They don't have to be everything for everyone, and I accept that Scala is extendable. But, if there is a built-in library, then surely it should be rock solid and as fast as the language have to offer.

I'm lodging a complaint with Star Command ;-)

Does anyone know where or how a normal guy like me can voice my opinion on this, i.e. where we can go to help shape the Scala language?

Update:

This question was not intended in any negative way. Scala, it's creators and the Scala community is choc-full off goodness. I was simply surprised to see that something like the built-in JSON parser was far from optimal (according to the question in the link provided)

Improve this question
2
  • Oh, how lovely it would be if I could accept all these clever answers. Thanks everyone.
    – Jack
    Mar 5, 2012 at 9:39
  • Update: Parser combinators have been split into a separate jar file and the JSON parser has been deprecated.
    – soc
    Jul 14, 2013 at 16:03

6 Answers 6

Reset to default
13

The built-in libraries should be perfect.

In an ideal world, yes. But perfect is the enemy of good. Any real creation is always some sort of trade-off. It can be a trade-off between performance and flexibility, for example. Or performance vs. the effort to write the library. If it's "good enough for now" and there are more critical issues to work on, then it's better to focus on those more critical issues. Optimizing for speed only is usually false economy.

One important point in language / library / API trade-offs is that changing interfaces later on is hard because it usually breaks old code built on top of the interface. But the implementation (i.e. speed) can be improved later on, so initially you can skimp on it, if it helps to focus the effort on getting the interface right. The order of importance is:

  1. Interface. Syntax. File formats. Hard to modify after release. Must strive to get right initially.
  2. Stability, correctness. Things should of course work as they're supposed to. But if not, can be fixed.
  3. Performance, speed. Sometimes crucial, most often not. Can definitely be improved later on.

Does anyone know where or how a normal guy like me can voice my opinion on this, i.e. where we can go to help shape the Scala language?

I think the keyword here is "bottleneck". If you have a real use case where the performance of the JSON library is the bottleneck, then you could bring the issue up in Scala mailing list. If you can improve it yourself, good, but if someone else is supposed to improve it, there must at least be a genuine need for it.

Improve this answer
1
  • +1 for perfect is the enemy of good. In reminding me of what I already know, you have just saved me a couple of hours. Thanks
    – Jack
    Mar 5, 2012 at 9:36
9

The JSON parser that comes with the standard library is based on the parser combinators. Parser combinators makes it possible to create parsers that are easy to understand and modify, and do so very quickly. The whole grammar for JSON is defined on lines 134 to 140 here. If you take a look at Lift JSON, you can't even pick a group of lines as representing the grammar.

However, parser combinators -- the Scala library at least (Haskell has them too) -- are slow. Maybe the packrat parser introduced on Scala 2.8 would perform better, but that JSON parser is much older, and, if I have my facts straight, it was created mostly as an example.

Now, should Scala only make available perfect libraries? Well, given the constrained resources available, the alternative is no JSON library at all. Today, that would be fine -- there are plenty alternatives, after all. But at the time JSON was added to the library, and before the widespread adoption of JSON made it performance-critical, it was something nice to have.

Improve this answer
1
  • +1 Solid answer as always D. Thanks for the link to the JSON source.
    – Jack
    Mar 6, 2012 at 7:22
3

If the creators of Scala were not to release any code until it is perfectly optimized to top performance, Scala would probably be at version 0.1, not 2.9.

Practically all new languages have performance issues initially. Think back to Java 1 (if you have any experience with it). This is because initially, the creators focus more on the language features and interfaces than the implementation details, and it is reasonable this way. Noone can predict how (and whether) a language and its class libraries are going to be used in the future (apart from the trivial cases like string library etc.). So it is better to optimize only when there is a real pressing need for it, than to spend time on optimizing a piece of code which won't actually make any visible difference in developers' life.

Moreover, Scala is special in that it is built on top of the JVM, so all the existing Java libraries are directly available from it. If you prefer performance over purity of language, you can always pick and use a suitable Java class / library.

Improve this answer
2

Its open source software. So compared with proprietary software the authors tend to be more candid about any failings. There is also no pretense that you have any way to influence development other than polite requests, or, writing the improvements yourself and respectfully submitting the improved code for inclusion in the general release.

Given the nature of Scala and the niche it occupies (large scale parallel processing ) the developers are probably right to give priority to the internal performance of code that may be executed several thousand times for a single request versus a JSON parser that will be executed only once per request.

Improve this answer
3
  • "So compared with proprietary software the authors tend to be more candid about any failings.": I would not take this as a rule, for example Windows 95 was very unstable and Microsoft was very candid about it (Windows only got really stable with Windows XP, i.e. many years later).
    – Giorgio
    Jul 18, 2013 at 19:28
  • Ah the good old days -- MS no longer listens, just consider the Windows 8 Start button fiasco.
    – James Anderson
    Jul 25, 2013 at 2:17
  • If you have a monopoly you do not need to listen too much: it is your customers that must listen to you.
    – Giorgio
    Jul 25, 2013 at 6:13
2

Given the abundance of fast open-source JSON parsers for the JVM, this looks like a perfect example of not invented here. A built-in feature that is magnitudes slower than already existing implementations is an indication that the makers of the language don't care too much about real-world usage, at least as far as this feature is concerned.

Improve this answer
0

So fix it. This is how open-source works my man. You have an itch, you scratch it. You do know you can run Java JSON parsers in Scala, right?

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.