Hi Robert, I am now confused. While your original reply to this thread made perfect sense to me, your follow up for the purposes of clarification had the opposite effect, at least for me. I am not clear the point you are trying to make.
You mention the difference between compiled and interpreted and point out that typically there is not a large performance difference — where I assume you were referring to use of standard library functions in the interpreted language such as *json_decode()* in PHP. That is of course often true and I concur. *(Of course, try writing a full JSON parser in pure PHP and we'll find a big difference in performance with a compiled language like Go.) * But I am not seeing why that point is relevant in the thread because she was not asking *"Why is PHP code slower than Go code?"* in which case I would understand why you chose to make that distinction. You also mention that IO performance *(and design(?))* over the web is typically much more relevant performance-wise, on which I also concur, but given that both her PHP and her Go API endpoints presumably had much the same web-based latency and response time concerns, I'm struggling to understand why it was relevant to state it in this context. Of course your point simply could have been not using a buffered output stream, but you already mentioned, and your follow up did not make that connection clear. So, can you please help me better understand the point you were trying to make? As a follow up to my reply were you trying to imply that illustrating ways to optimize JSON parsing was something you felt I should not have posted in response to her question? That feels like in might have been your intent, but I could certainly have misinterpreted and if so would prefer to know rather than wrongly assume. -Mike On Friday, March 8, 2024 at 8:28:38 PM UTC-5 Robert Engels wrote: > Just to be clear for others - from a raw cpu performance perspective when > looking at a typical application in whole - there is very little > performance difference between compiled and even GC platforms- interpreted > can lag behind a bit - but in almost all cases over the web it is IO > performance/design that matters the most (most middleware connects to other > middleware, etc). > > Some HFT/HPC systems deviate from this but by the description and > reference to the previous implementation I doubt that is the case here. > > On Mar 8, 2024, at 6:53 PM, Mike Schinkel <mi...@newclarity.net> wrote: > > Hi Pragya, > > > While Robert Engles is probably correct in identifying your bottleneck, if > it does turn out to be slow JSON parsing here are a few things you can > look at <https://yalantis.com/blog/speed-up-json-encoding-decoding/>. > > 1. You mention you have to use a map because of response keys not being > fixed. Be aware that you *do not need to > <https://stackoverflow.com/a/33222371/102699>* create a struct to match > the full JSON. You can easily just create a flyweight struct which is a > subset if for your use-case containing only the specific parts you need, *for > example* <https://goplay.tools/snippet/c5qV5MfwAb->. > > 2. If you optionally need to parse portions of the JSON, but not always, > you can use *json.RawMessage* > <https://stackoverflow.com/a/52250578/102699> to capture the properties > you don't always need to parse, and then *parse them only when you need > to <https://stackoverflow.com/a/23256630/102699>*. > > 3. You can also declare an *.UnmarshalJSON()* method on a struct you are > passing to *json.Unmarshal()*, or on any struct that is a property of > your top level object, and then be *fully in control of parsing the data* > <https://stackoverflow.com/a/65275814/102699>, meaning you could combine > with (a) *json.RawMessage* property(s) to part just the non-fixed keys as > a map, and only for use-cases when you need to. > > 4. And finally, if you are willing to venture out from the Go standard > library, there are numerous open-source packages that claim to be much > faster than the standard library. Usually you want to stick with the Go > standard library so other Go developers will be familiar with it and to > minimize dependencies that could potentially introduce a bug or security > hole. However, if you really need better performance it might be worth the > added dependency. > > While I cannot validate the performance claims of any of these packages, I > can provide you with this list of packages that claim better JSON > unmarshalling performance: > > - https://github.com/valyala/fastjson > - https://github.com/bytedance/sonic > - https://github.com/buger/jsonparser > - https://github.com/mailru/easyjson > - https://github.com/sugawarayuuta/sonnet > - https://github.com/json-iterator/go > - https://github.com/segmentio/encoding > - https://github.com/goccy/go-json > - https://github.com/simdjson/simdjson > > Benchmarks from authors of some of the packages *(so take with a grain of > salt):* > > - https://github.com/sugawarayuuta/benchmark > - > https://blog.min.io/simdjson-go-parsing-gigabyes-of-json-per-second-in-go/ > > And benchmarks from someone who is not an author of one of those packages: > > - > > https://kokizzu.blogspot.com/2022/12/map-to-struct-and-struct-to-map-golang.html > > > Hope this helps. > > -Mike > On Friday, March 8, 2024 at 4:15:25 PM UTC-5 Robert Engels wrote: > >> It is highly unlikely that the Go marshaling is the cause. I’m guessing >> you are probably not using a buffered output stream. >> >> PHP is written in C but depending on what you are doing it is either a >> script or calling out to another process (afaik) >> >> On Mar 8, 2024, at 2:35 PM, pragya singh <pragy...@gmail.com> wrote: >> >> Hi, >> >> >> "I am facing an issue in my Go code. I converted my read API from PHP to >> Go, but the response time of Go API is higher than PHP. We are returning >> the response in JSON format, and the response contains around 30k keys, >> which is taking too much time in JSON marshaling. We are adding all the >> response in map format as we can't use struct because response keys are not >> fixed and vary from user to user. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/a57a2a71-b0f9-41fb-93e9-bd54b57829b1n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/a57a2a71-b0f9-41fb-93e9-bd54b57829b1n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/7345c383-1529-489c-b156-72601bd80530n%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/7345c383-1529-489c-b156-72601bd80530n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/01d857e5-c7ec-431f-9f27-775c2411da05n%40googlegroups.com.
