Mapcache
Warning! This is the old Hercules bugtracker archive, and may not reflect the current state of Hercules. The current bugtracker is on GitHub Issues.
Issue information
Issue ID
#162
Status
Fixed
Severity
None
Started
Hercules Elf Bot
Oct 1, 2007 12:57
Last Post
Hercules Elf Bot
Apr 5, 2012 8:32
Confirmation
Hercules Elf Bot - Oct 1, 2007 12:57
Originally posted by [b]flaviojs[/b]
http://www.eathena.ws/board/index.php?autocom=bugtracker&showbug=162
Continuation of ticket #73. (Backup of the page is attached)
There should always be the possibility of saving data as raw. And yes, it's better to change MC_ENTRY_COMPRESSED to MC_ENTRY_DEFLATE (algorithm used to decompress) so other formats can be added freely in the future.
Note that any change in the format must advance the version of the format. Advancing the major version if the file header changes or a feature in the previous version is no longer supported, otherwise advancing the minor version.
-----
Every file operation is slow, with the map headers packed together you can just read everything in one go and do the rest in-memory.
When maps are modified/updated/removed the new format can have better performance because data doesn't have to be moved around as often, only the map-list has to be rewritten every time (small part of the file).
Note that the current trunk implementation has O(N^2) file accesses when searching for a map. With the headers packed together you get O(1).
-----
http://www.eathena.ws/board/index.php?autocom=bugtracker&showbug=162
Continuation of ticket #73. (Backup of the page is attached)
QUOTE(DracoRPG)
- Is there a reason to keep an "uncompressed" alternative? I'm afraid no map is small enough to be smaller unzipped than zipped. I understand it costs nothing to leave it in, though. Maybe make the name MC_ENTRY_ZIPPED so we can add other compression algorithms later if we wish?
There should always be the possibility of saving data as raw. And yes, it's better to change MC_ENTRY_COMPRESSED to MC_ENTRY_DEFLATE (algorithm used to decompress) so other formats can be added freely in the future.
Note that any change in the format must advance the version of the format. Advancing the major version if the file header changes or a feature in the previous version is no longer supported, otherwise advancing the minor version.
-----
QUOTE(DracoRPG)
- Everytime you add a single map you'll have to rewrite the whole map list. How is packing map header & map data together less efficient? To read through the whole map headers list you just have to skip <size> bytes after each header (where <size> is the map data size read in the header). Is this operation so slow?
Every file operation is slow, with the map headers packed together you can just read everything in one go and do the rest in-memory.
When maps are modified/updated/removed the new format can have better performance because data doesn't have to be moved around as often, only the map-list has to be rewritten every time (small part of the file).
Note that the current trunk implementation has O(N^2) file accesses when searching for a map. With the headers packed together you get O(1).
-----
QUOTE(DracoRPG)
- Maybe "map cache" isn't the proper name for the shit anymore. I already thought about it but was too lazy to change the name. Now eApp is the time to change things for good, isn't it?
Dunno about names, i'll just stick with mapcache until a better name is offered. Thinking about eApp, i should also include the possibility of having the height of every cell of the map (something that was wanted for eApp). Attached File(s)
Hercules Elf Bot - Dec 17, 2011 6:22
Originally posted by [b]Ind[/b]
the mapcache engine was changed many times since this bug was filled
the mapcache engine was changed many times since this bug was filled