You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking again at the functions initializing the devices, I can assume that the Rusty compiler could optimize this response and generate it at the compilation stage.
If it were interesting to check the formation of the response on the fly, then, probably, it is necessary to store these values not in the code, but to take them from the database, external cache (Redis) or just from a file, for example. (if my proposal looks rough, then I apologize for my English)
If we want to check a static response, then in the code we can try to use sync.Pool(but I'm not an expert in go, it would be good if someone else watched it)
Looking again at the functions initializing the devices, I can assume that the Rusty compiler could optimize this response and generate it at the compilation stage.
If it were interesting to check the formation of the response on the fly, then, probably, it is necessary to store these values not in the code, but to take them from the database, external cache (Redis) or just from a file, for example. (if my proposal looks rough, then I apologize for my English)
If we want to check a static response, then in the code we can try to use sync.Pool(but I'm not an expert in go, it would be good if someone else watched it)
The text was updated successfully, but these errors were encountered: