I've seen no newer plugins using json.encode to save tables instead of serialize, is there a benefit or difference between the two methods?
Is there a speed difference?
Thanks.
Is there a speed difference?
Thanks.
Json vs. Serialize
Posted by Rene on Thu 28 Jun 2018 09:43 PM — 5 posts, 22,578 views.
That's an interesting question. If there is a speed difference, I can't imagine a scenario where it would be enough to matter.
The encoding of both Lua serializing and Json serializing is done in Lua, so they would be comparable speeds.
The decoding of Lua is done in C (by the Lua engine) however the decoding of Json is done in Lua (using the LPEG module) so that would probably be slightly slower.
If you are using large enough amounts of data that speed is an issue, you might want to use an SQLite3 database instead. That is what I did for the mapper module which had to store data about thousands of rooms.
The decoding of Lua is done in C (by the Lua engine) however the decoding of Json is done in Lua (using the LPEG module) so that would probably be slightly slower.
If you are using large enough amounts of data that speed is an issue, you might want to use an SQLite3 database instead. That is what I did for the mapper module which had to store data about thousands of rooms.
Thanks, I do not know the first think about SQLite3 or databasing, any suggestions on where to start? Also simple plugin examples I find I learn the best from.
Thanks.
Thanks.
I have some posts about databases at:
http://www.gammon.com.au/db
http://www.gammon.com.au/sql
There are some examples there. It may be hard, however, if you aren't used to the general ideas behind SQL.
Try reading some SQL tutorials. Basically you:
Tables are generally a collection of like things (eg. inventory items). If a thing can have multiple "sub-things" (for example, a room with multiple exits) you generally (almost always) would have a second table. One for the room, and one for the exits. The exits table entries would "point" to the room they "belong" to.
If the room could contain other things (eg. shopkeepers) then you might make a third table, one which has the shopkeeper information. And if each shopkeeper stocked multiple items you might have another table with those items in it.
And now imagine that the same item (eg. a loaf of bread) could be sold by multiple shopkeepers. Then you might need another table again which connects the shopkeepers that sell bread to the bread item. You don't need this for a room exit, because an exit always belongs to a particular room, but bread might "belong" to multiple shopkeepers.
A good tutorial in SQL should walk you through this stuff.
Alternatively, stick to serializing tables, unless you have thousands of items. Be aware that if the program happens to crash while you are writing out the serialized file you might lose everything because you are overwriting the earlier file (unless you take steps to avoid that, like making a new file and renaming it when you are done).
SQLite3 is supposed to be pretty safe during a crash, as it has mechanisms to roll back the data to the last completed transaction.
http://www.gammon.com.au/db
http://www.gammon.com.au/sql
There are some examples there. It may be hard, however, if you aren't used to the general ideas behind SQL.
Try reading some SQL tutorials. Basically you:
- Create a table: CREATE TABLE ...
- Put items (rows) into the table: INSERT INTO ...
- Change things as required: UPDATE ...
- Get data back: SELECT ... FROM ...
Tables are generally a collection of like things (eg. inventory items). If a thing can have multiple "sub-things" (for example, a room with multiple exits) you generally (almost always) would have a second table. One for the room, and one for the exits. The exits table entries would "point" to the room they "belong" to.
If the room could contain other things (eg. shopkeepers) then you might make a third table, one which has the shopkeeper information. And if each shopkeeper stocked multiple items you might have another table with those items in it.
And now imagine that the same item (eg. a loaf of bread) could be sold by multiple shopkeepers. Then you might need another table again which connects the shopkeepers that sell bread to the bread item. You don't need this for a room exit, because an exit always belongs to a particular room, but bread might "belong" to multiple shopkeepers.
A good tutorial in SQL should walk you through this stuff.
Alternatively, stick to serializing tables, unless you have thousands of items. Be aware that if the program happens to crash while you are writing out the serialized file you might lose everything because you are overwriting the earlier file (unless you take steps to avoid that, like making a new file and renaming it when you are done).
SQLite3 is supposed to be pretty safe during a crash, as it has mechanisms to roll back the data to the last completed transaction.