Fails to Get/Parse Valid JSON

[nahtnam]

• VSCode Version: 1.26.1
• OS Version: 10.13.5
• REST Client Version: 0.19.1

Steps to Reproduce:

1. Make a test.http file.
2. Add the following

GET https://gist.githubusercontent.com/nahtnam/cd842afc31d90c3417c060e926fca656/raw/dc9f6d41a4613e7c56d4cc8458719b0b6130cf39/sample.json

3. Run it

It will get stuck and not show anything and eventually slow down the rest of vscode as well.

[Huachao]

@nahtnam it seems that I can view the response successfully except that it will cost a longer time.

[nahtnam]

Ah I see, it takes about 25 seconds to load, and even then it is un-prettified. Is there any way to increase the performance? The API returns within 300ms so it should really only take a few seconds max right?

[Huachao]

@nahtnam the root cause of this question is that the content-type of response body is not application/json, it's text/plain instead. In current logic, if it's not known MIME type, like json, xml and so on, I can't figure out what the language of the response to highlight. And I will use the auto highlight logic of the highlight library which costs a lot of time. So I have prepared a fix that when deciding the highlight language of response body, I will consider both content-type of response body and the content of the response body. So for your case, although the content type is not json, when I check the content of the response body, it's json actually, I will use the json language to highlight the response body, not the auto mechanism.

[Huachao]

@nahtnam after the update, it will take less than 10 seconds to load. I will keep improving the performance for rendering.

[nahtnam]

Awesome, any idea when this feature will be released into the market?

Really appreciate the work done here, this library is very useful!

[Huachao]

@nahtnam I would like to publish a new release together with other features and bug fixes in early September.

[nahtnam]

Gotcha, awesome, thanks!

[nahtnam]

Actually @Huachao The issue is still there. Please try with this API URL: https://apituner.ecbsn.com/apituner/v1/store/reward/list?channel=4

On my computer, it takes forever and eventually ends up freezing VS Code. Is it because the JSON is big and VS Code cannot handle it or is it because you are processing the JSON?

[nahtnam]

I don't completely know how the whole system but could it be a possibility that js-beautify is the bottleneck? JSON.stringify({ hello: 'world' }, null, 2) is very very fast, is it possible to use that instead (if the only thing you use beautify is for making the JSON pretty)?

[Huachao]

@nahtnam the e2e latency for a user to view a complete response in the panel in my extension can be divided into three phases:

1. Send the request and wait for the response (Spinner keep spinning in the status bar)
2. Do some post-processing jobs for the response in my extension like Prettify the response body, Identify the links in response body, Calculate line number, Syntax highlight. (Spinner froze in the status bar)
3. VSCode do the rendering HTML job (Spinner disappeared, replaced with duration and response size, and a response panel already created, however with no content)

And in my test from my local machine, I can see the first phase costs only <1s, the second phase costs <8s, and the last rendering phase costs <15s.

So can you calculate the duration for each phase to see which part costs the most? In my previous data, the bottleneck is from the third phase, not the second phase. And I will keep improving the performance of my extension in the second phase.

And back to your question, why do we need a third party library like js-beautify, can we use the built-in JSON object? I have to say no, the story is a bit more complicated. Firstly, we can't do the stringify directly, since what we have is the response body, it's a string, not an object. So if we would like to use it, we need deserialize first and serialize back. However, in the deserialize and serialize process, we may lose some information, consider the following example,

{"value": 1.0}

After the deserialization and serialization process, the result will be

{
   "value": 1
}

And the fraction part is lost. So we can't simply use this way although this is the fastest way in my perf test. So I have to use a prettify libray like js-beautify which is the fastest way in my test.

[Huachao]

@nahtnam I have improved the performance of the second phase (processing received response), the duration costs less than 2 seconds on my local machine for your request. I'd like to close it. I will publish the fix in next release.

[Huachao]

@nahtnam you can try the latest version 0.21.0 to verify