The app I wrote has a background process which parses a JSON file every 30 minutes. Used to work fine, but the past couple of weeks it's been having issues. Looking at the logs, the error that pops up is:
Message: Data provided to Background.exit() is too large
The file is only 1.2Kb. That doesn't seem too large. Anything else which may be triggering this error?
TrailCat the output you posted doesn't distinguish between strings and numbers, due to the way System.println works with objects, which I think is crucial in this case.
Looking at the original JSON, it looks to me like your daily forecast has the "min" and "max" values as strings when they could be numbers. You have a few other numbers, like "windspeed" and "forecast_high" which are being returned as strings. You should see a lot of savings if you change all your numerical strings to numbers. A number or float is 4 bytes, and the equivalent string is a lot bigger.
Other things you could optimize, which are probably less crucial: - Change the day of week string -- e.g. "Mon" -- to an integer -- e.g. 0. - If you're *still* stuck at this point, you could shorten the names of all your keys, but I'm guessing that wouldn't be necessary in this case. Just an educated guess, tho. But if one day you have a similar problem, and you absolutely need to save just a handful of bytes, that would be the way to do it.
To Jim, FlowState, and Travis, thanks for all your suggestions. This really helps out and I will try them later on tonight. This was exactly what I was looking for from reporting error codes to optimizing my code. I'm learning along the way with all your help.
Any suggestions as far as working with the simulator to find any memory leaks and such? Trying to learn more debugging and optimization techniques since you guys gave some great advice.
I don't see anything that would indicate min/max are strings, but it's easy to check with instanceof in the code. Station_update is a string, and there, since you're building the response, I'd use "unix time" (it's a number), as that way, you can use the users local time to display it (and doing so actually makes it smaller)
Look at reducing the key/value pairs - maybe by using an array or something.
I don't see anything that would indicate min/max are strings,
It's in the original JSON itself, like I said. If you click on my link, or click on his text file and follow the original link, you will see for yourself.
There are actually dozens of numerical strings in the JSON....
OK, had a chance to update the JSON file I generate which is now 949 bytes and I eliminated most of the strings. Haven't had any issues with Background processes after a couple temporal events, so I think I may be good!
Another trick I have used is replacing dictionaries with a list if the dictionary items are known. Since you can control it, you can have a predetermined order of fields. This way you avoid the overhead of the dictionary labels. Then just access the data as an array with indices created in an enum. Lots of ways to reduce data when necessary.
I just ran into this today. Running out of memory for my app and had a web request that was adding 6k to the working set. Changed it from a dictionary that contained 2 arrays of dictionaries with each of those sub dictionaries having 4 fields to the following. Also noticed some of my integers were being stored as strings so fixed that. After the changes, it went down to under 1k.
- I included an attached file with sample code as I couldn't post it here without getting errors. -
Not the prettiest, but very data efficient.
I could have made it in to a single long array but this made it much easier to iterate through the 2 separate lists of records and it would have only saved a few bytes.
