[squeak-dev] I'd like to contribute to the JSON project

Tobias Pape Das.Linux at gmx.de
Mon Nov 23 18:09:47 UTC 2020



> On 23. Nov 2020, at 18:08, Levente Uzonyi <leves at caesar.elte.hu> wrote:
> 
> On Sun, 22 Nov 2020, Tobias Pape wrote:
> 
>> 
>> 
>>> On 22. Nov 2020, at 19:37, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>>> Hi Tobias,
>>> On Sun, 22 Nov 2020, Tobias Pape wrote:
>>>>> On 22. Nov 2020, at 18:51, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>>>>> Hi Tobias,
>>>>> On Sun, 22 Nov 2020, Tobias Pape wrote:
>>>>> Three reasons:
>>>>> 1. performance
>>>>> | j s |
>>>>> Smalltalk garbageCollect.
>>>>> j := JsonObject new
>>>>> 	foo: 1;
>>>>> 	bar: 2;
>>>>> 	baz: 3;
>>>>> 	yourself.
>>>>> s := Symbol allSymbols.
>>>>> {
>>>>> 	[ s do: [ :each | ] ] bench.
>>>>> 	[ s do: [ :each | j respondsTo: each ] ] bench.
>>>>> 	[ s do: [ :each | j respondsTo2: each ] ] bench. "Your suggested implementation"
>>>>> }
>>>>> #(
>>>>> 	'1,630 per second. 613 microseconds per run. 0 % GC time.'
>>>>> 	'19 per second. 52.7 milliseconds per run. 0.09992 % GC time.'
>>>>> 	'1.18 per second. 850 milliseconds per run. 32.81709 % GC time.'
>>>>> )
>>>>> Okay, that may not be too a realistic workload. The reason of the extreme
>>>>> slowdown and high GC time is rapid interning and GCing of Symbols
>>>>> created by #asSimpleGetter.
>>>>> If you change s to a handcrafted array that avoids Symbol creation, like
>>>>> s := #(yourself foo foo: bar bar: baz baz: foobar foobar: name name:)
>>>>> the numbers get better but still not as good as my suggestion:
>>>>> #(
>>>>> 	'4,970,000 per second. 201 nanoseconds per run. 38.02 % GC time.'
>>>>> 	'147,000 per second. 6.82 microseconds per run. 1.74 % GC time.'
>>>>> 	'92,300 per second. 10.8 microseconds per run. 1.09978 % GC time.')
>>>> I thought you'd say that.
>>>> But "precedence" is one of the most obscure things around that part in the image.
>>>>> 2. backwards compatibility
>>>>> #isSimpleSetter and #isSimpleGetter are available since Squeak 5.3. I use this code in 5.1 and 5.2 images as well.
>>>> Yea, Pre 5.3 I'd have said #asMutator.
>>>>> 3. to use the same mechanism as #doesNotUnderstand:
>>>>> Have a look at that method.
>>>> Then I'd rather say change DNU too.
>>>> If you're down that hole (dnu/respondsTo) anyways, I don't buy the performance argument anymore.
>>>> Not everything has to be as fast as possible.
>>> You seem to ignore that #doesNotUnderstand: is the most often used method of JsonObject.
>>> I assume you don't use the JSON package in production images, hence you don't care about performance.
>> 
>> I do.
>> It never has been the bottleneck.
>> 
>>> I do, so I'm not willing to change the implementation of #doesNotUnderstand: in my fork of the JSON package unless performance is at least as good as it is now.
>> 
>> I just want the image to remain tractable.
> 
> Does having a method or two implemented in an external package affect that? Also, have you ever had a look at how other stuff is implemented in that package?

Been a while. 
I've used it for some years now but lately, I've not looked into the implementation anymore, no.

> 
>> Performance is nice. But if you rely on performance with the JSOn stuff,
>> subclass the JsonObject and implement your keys as messages? That ought to be the fastest way, no?
> 
> It depends on how your JsonObjects are created.  If you parse a json from an external source, you can't do that unless you hardcode the structure of the json into your application.

Yes, exactly.

> 
>> I though it was meant to be that way.
>> 
>> That said, I rarely remain in the JSON space for longer than necessary; I'd rather have proper objects and only convert on "the edges"
> 
> See above.

Best regards
	-Tobias


> 
> Levente
> 
>> 
>> I'm not against fast things.
>> I'm merely a bit startled by fast things that are harder to understand than necessary…
>> 
>> Best regards
>> 	-Tobias
>> 
>> PS: Levente, your code is almost always the fastest variant of anything we discuss on here. That's amazing in itself. Don't get the impression I'm not amazed by that ;)
>> 
>>> Levente
>>>> Best regards
>>>> 	-Tobias
>>>>> Levente




More information about the Squeak-dev mailing list