-
Notifications
You must be signed in to change notification settings - Fork 36
Options for Maximum Performance
JSONConfig.setValidatePropertyNames(false) will disable property name validation, saving you a complex regular expression check on every field in every object.
JSONConfig.setDetectDataStructureLoops(false) will disable data structure loop checks. It's not very expensive but it's more than zero. It's unnecessary if you have no nested objects or if you know for a fact that you have no loops, which most good coders do know.
JSONConfig.setFastStrings(true) will disable all validation of string values. This will give you a nice performance boost but if your strings have anything that's not kosher for JSON then your JSON will be broken in a strict JSON parser and possibly for Javascript eval()
Numbers formatted with custom number formats have to be checked with a regular expression to make sure that they produce JSON standard compliant numbers. If you don't use them then the number's toString() method is called. In that case then Bytes, Shorts and Integers are not checked at all and Longs are only checked for precision loss if JSONConfig.isPreciseNumbers() returns true but even that check is pretty quick. Floats and Doubles are only checked for Infinity and NaN which are not allowed in JSON (and get quoted). BigDecimal and BigInteger are only checked that they don't get converted to Infinity when they are converted to Double unless JSONConfig.isPreciseNumbers() returns true in which case they are also checked for precision loss and that check is a little expensive.
Reflection is expensive, though it's not too bad with JSONUtil.setCacheReflectionData(true). Maps are faster. There's no way around that.
Escaping all surrogates or all non-ASCII can involve a lot of escaping. Escaping is expensive.
Escaping bad identifier code points will also slow things down, even if it doesn't have to do any actual escaping because even the checking is expensive.
JSONConfig objects are not thread safe so they should never be shared between threads but as long as you always use them in a single thread, you can improve performance slightly by always sending an explicit JSONConfig to JSONUtil.toJSON(*) and reusing them within a single thread.
Due to synchronization in JSONConfigDefaults, it is slightly quicker to clone a JSONConfig object than it is to create a new one, especially if there are a lot of threads trying to create JSONConfig objects at the same time because only one thread at a time can create one from scratch. The JSONConfig.clone() uses a private constructor that doesn't use synchronization because it doesn't have to access anything from JSONConfigDefaults.