Float with exponential value issue

[Sanju9026]

Hi,

This is working good until i have a value in json string as exponential.

ex:

var str = "{ \"Float\" : 3.1415926e+23}"

this is not coming as json format.

Below is full string- let json = """ [ { "float" : 3.1415926e+23, "negative_numbers" : -50, "bool_true" : true, "bool_false" : false, "null" : null, "url" : "http://www.apple.com", "url_with_escape" : "https:\/\/www.github.com", "url_without_protocol" : "stackoverflow.com", "unsupported_url" : "172.168.0.1", "empty_string" : "", "empty_array" : [], "empty_object" : {}, }, { "effects_in_array" : [ "string", 3.1415926, -50, true, false, null, "http://www.apple.com", "https:\/\/www.github.com", "stackoverflow.com", "172.168.0.1", "aaa.com.bd", "test-aaa.com.bd", "", [], {}, ] }, { "quotes_string": "This is a string that has some \"quotes\" inside it!", "very_long_value" : "A very very very very very very very very very very very very long string." }, { "nested" : { "object" : { "array" : [ "string", [ { "key" : "value" } ] ] } } }, { {123456} } ] """

[rakuyoMo]

I have fixed this issue on the develop branch.

I will release a new version later, have fun.

[rakuyoMo]

Hold on, I'm thinking if I need to support the case where E is used alone? For example 1.99714E130, is this a legitimate scientific and technical method representation?

[Sanju9026]

I am not sure for this

Hold on, I'm thinking if I need to support the case where E is used alone? For example 1.99714E130, is this a legitimate scientific and technical method representation?

I am not sure about this situation. Is this really a valid case or not but float with value 3.123344e+23 and 3.438595e-24 are the valid values

[Sanju9026]

I have fixed this issue on the develop branch.

I will release a new version later, have fun.

Even i have fixed this issue but because of that fix, displaying json got little delay and it slow down my performancealso( was using 6k line of json string to display)

[rakuyoMo]

I have fixed this issue on the develop branch. I will release a new version later, have fun.

Even i have fixed this issue but because of that fix, displaying json got little delay and it slow down my performancealso( was using 6k line of json string to display)

Are you using the fix I just submitted? If so can you provide me with your json content? If it's not publicly available you can send it to my email (rakuyo.mo@gmail.com)

By the way, how much time is it taking for you to render the 6,000 lines of json?

[rakuyoMo]

I am not sure for this

Hold on, I'm thinking if I need to support the case where E is used alone? For example 1.99714E130, is this a legitimate scientific and technical method representation?

I am not sure about this situation. Is this really a valid case or not but float with value 3.123344e+23 and 3.438595e-24 are the valid values

I have now added full support for scientific notation. Contains {E/e}[+/-]

[Sanju9026]

I have fixed this issue on the develop branch. I will release a new version later, have fun.

Even i have fixed this issue but because of that fix, displaying json got little delay and it slow down my performancealso( was using 6k line of json string to display)

Are you using the fix I just submitted? If so can you provide me with your json content? If it's not publicly available you can send it to my email (rakuyo.mo@gmail.com)

By the way, how much time is it taking for you to render the 6,000 lines of json?

It takes around 5-10 seconds and after that to minimize and maximize node also takes time even scrolling too. One more thing, i am using swiftui in which i am calling this uikit view. Is there any way to use this directly in swiftui instead of merging uikit into swiftui view?

[Sanju9026]

I am not sure for this

Hold on, I'm thinking if I need to support the case where E is used alone? For example 1.99714E130, is this a legitimate scientific and technical method representation?

I am not sure about this situation. Is this really a valid case or not but float with value 3.123344e+23 and 3.438595e-24 are the valid values

I have now added full support for scientific notation. Contains {E/e}[+/-]

Great

[rakuyoMo]

It takes around 5-10 seconds and after that to minimize and maximize node also takes time even scrolling too.

I doubled the json in the example by 10 times, i.e. 7000 lines of json. and ran it 10 times on an iPhone XS Max running iOS 14.7.1, taking the average rendering time.

Without adding scientific notation support, the average rendering time was 2.3 seconds. With scientific notation support, the average rendering time was 2.9 seconds.

Neither code caused sliding lag, but the collapse time did increase with the json length.

I will try to optimize my code again, but probably at a later time.

Also, JSONPreview does currently have a performance bottleneck, which is a known issue. It doesn't use some asynchronous rendering methods to speed up rendering, or use CoreText. i may set aside some time in the future to optimize its performance specifically.

_Also JSONPreview uses native methods to parse JSON, which means it has to iterate through every character in the JSON. So not only does JSON length affect parsing speed, but line length still has a huge impact._

One more thing, i am using swiftui in which i am calling this uikit view. Is there any way to use this directly in swiftui instead of merging uikit into swiftui view?

As mentioned here: #4, JSONPreview may support SwiftUI in the future, but not now. It will probably be in the middle of this year, or at some point in the second half of the year.

[Sanju9026]

It takes around 5-10 seconds and after that to minimize and maximize node also takes time even scrolling too.

I doubled the json in the example by 10 times, i.e. 7000 lines of json. and ran it 10 times on an iPhone XS Max running iOS 14.7.1, taking the average rendering time.

Without adding scientific notation support, the average rendering time was 2.3 seconds. With scientific notation support, the average rendering time was 2.9 seconds.

Neither code caused sliding lag, but the collapse time did increase with the json length.

I will try to optimize my code again, but probably at a later time.

One more thing, i am using swiftui in which i am calling this uikit view. Is there any way to use this directly in swiftui instead of merging uikit into swiftui view?

As mentioned here: #4, JSONPreview may support SwiftUI in the future, but not now. It will probably be in the middle of this year, or at some point in the second half of the year.

ok

[Sanju9026]

It takes around 5-10 seconds and after that to minimize and maximize node also takes time even scrolling too.

I doubled the json in the example by 10 times, i.e. 7000 lines of json. and ran it 10 times on an iPhone XS Max running iOS 14.7.1, taking the average rendering time.

Without adding scientific notation support, the average rendering time was 2.3 seconds. With scientific notation support, the average rendering time was 2.9 seconds.

Neither code caused sliding lag, but the collapse time did increase with the json length.

I will try to optimize my code again, but probably at a later time.

Also, JSONPreview does currently have a performance bottleneck, which is a known issue. It doesn't use some asynchronous rendering methods to speed up rendering, or use CoreText. i may set aside some time in the future to optimize its performance specifically.

_Also JSONPreview uses native methods to parse JSON, which means it has to iterate through every character in the JSON. So not only does JSON length affect parsing speed, but line length still has a huge impact._

One more thing, i am using swiftui in which i am calling this uikit view. Is there any way to use this directly in swiftui instead of merging uikit into swiftui view?

As mentioned here: #4, JSONPreview may support SwiftUI in the future, but not now. It will probably be in the middle of this year, or at some point in the second half of the year.

Thankyou for you detailed information.

[Sanju9026]

By mistake it got closed So i reopen. I am extremely sorry.

[rakuyoMo]

@Sanju9026 I'm very sorry I don't have a good way to improve the parsing efficiency yet.

If the content of the json you want to preview is manageable, it is recommended that you segment the json as much as possible and reduce the content of each line.

But that doesn't mean it's over. I'll continue to explore how to improve the efficiency of json parsing later.

For now I'm going to release version 1.3.6 with the existing content, and after that I'll reply and close this issue.

[rakuyoMo]

Now version 1.3.6 has been released.

[Sanju9026]

Now version 1.3.6 has been released.

Thankyou @rakuyoMo

[rakuyoMo]

Development of 2.0.0 is now officially underway, but no completion date can be guaranteed. Anyone can check the 2.0.0 branch for details.

[rakuyoMo]

@Sanju9026 Now version 2.0.0-beta has been released with amazing performance improvements.