Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Comments on Does using an Integer have any speed/performance benefits over a string in JSON
Parent
Does using an Integer have any speed/performance benefits over a string in JSON
I'm working on an API to respond some data about a bunch of orders and items.
The order and item numbers are always an integer (it's the order.id and item.id value, respectively).
Originally the response included each order number and each item number as a string, something like:
{
"orders": [
{
"id": "12345",
"item": [
"123",
"124",
"125",
"126"
]
},
{
"id": "95812",
"item": [
"173",
"198"
]
}
]
}
I instructed the team to make the values as integers rather than strings, that exact response now looks like:
{
"orders": [
{
"id": 12345,
"item": [
123,
124,
125,
126
]
},
{
"id": 95812,
"item": [
173,
198
]
}
]
}
My question is if there is really any purpose to what I've done? We're never going to need to perform any mathematical equations on the number, essentially they are functioning as strings (as far as I'm aware).
Perhaps it's counterproductive because now an order number cannot contain any other character besides a number - but that's anyhow how it works since it's using an INTEGER type in the database.
There's always the smaller and therefor faster response - since there's no ".
In the above example (minified) it's almost 17% smaller.
- string = 96 bytes
- int = 80 bytes
Post
Let's start with this perl at https://www.json.org/json-en.html:
A number is very much like a C or Java number, except that the octal and hexadecimal formats are not used.
That's an extremely imprecise sentence. There are no numbers in C or Java. C provides signed and unsigned short, int, long, long long numeric types, and thin character types which allow some arithmetic. Java provides signed byte, short, int and long numeric types, their wrapping classes counterparts, and a Number superclass.
That clarified, you should stick to strings for the sake of security. That decreases the probabilities of overflowing the parser. Instead of having developers using a maybe happy times parser which may possibly believe (wrongly (or at least eventually wrongly)) that the number will fit default numeric types, have developers retrieve a number encapsulated in a string, with no doubt the parser isn't overflowing, and then let they explicitly choose between:
-
Make the wrong assumption that the number will fit the numeric type.
-
Asserting that the number fits, and fail to assert if it does not.
-
Feeding the number to a big integers parser, provided by some third party library (or your code), in the case of C; or provided by the language, in the case of Java.
0 comment threads