Zipped but not compressed
Post MTG Forge Related Programming Questions Here
Moderators: timmermac, Blacksmith, KrazyTheFox, Agetian, friarsol, CCGHQ Admins
4 posts
• Page 1 of 1
Zipped but not compressed
by mtgrares » 30 Sep 2010, 17:28
I just got done reading an article that suggested that some IO can be improved if you use an uncompressed zip file. It said that the official Java jar files are zipped but not compressed. I'm just throwing this out there as an idea that may improve Forge's startup time or for the individual card files.
- mtgrares
- DEVELOPER
- Posts: 1352
- Joined: 08 Sep 2008, 22:10
- Has thanked: 3 times
- Been thanked: 12 times
Re: Zipped but not compressed
by Rob Cashwalker » 30 Sep 2010, 17:43
As the card files go, I think with the card-per-file format, we've had huge leaps in the number of cards added, because it's easier to manage without conflicts.
The Force will be with you, Always.
-
Rob Cashwalker - Programmer
- Posts: 2167
- Joined: 09 Sep 2008, 15:09
- Location: New York
- Has thanked: 5 times
- Been thanked: 40 times
Re: Zipped but not compressed
by gestalt » 30 Sep 2010, 18:31
I think there is a way to do both.
You can create a cache with parsed objects. I know it is extra work but it can work nicely. When loading files, the program can first check whether the compiled version exists or not. If it exists loads the serialized version if not loads the individual card files and creates a serialized version. So next time it is run the load time is shorter. For additional convenience, you can create a checksum of the cards.txt files and store this checksum in the serialized version (using cardnames, modification times and file sizes for instance). This way the changes can be detected as well.
In the end early optimization is the root of all evil. So maybe a better approach is to first measure the impact of loading card files to the overall startup time.
Just my two cents...
You can create a cache with parsed objects. I know it is extra work but it can work nicely. When loading files, the program can first check whether the compiled version exists or not. If it exists loads the serialized version if not loads the individual card files and creates a serialized version. So next time it is run the load time is shorter. For additional convenience, you can create a checksum of the cards.txt files and store this checksum in the serialized version (using cardnames, modification times and file sizes for instance). This way the changes can be detected as well.
In the end early optimization is the root of all evil. So maybe a better approach is to first measure the impact of loading card files to the overall startup time.
Just my two cents...
- gestalt
- Posts: 8
- Joined: 09 Feb 2010, 08:00
- Has thanked: 0 time
- Been thanked: 0 time
Re: Zipped but not compressed
by mtgrares » 01 Oct 2010, 16:49
I like the saying "Early optimization is the square root of all evil". I tell myself this many times because optmization hacks are just that, hacks, which are generally evil (ie. bad programming practices).
- mtgrares
- DEVELOPER
- Posts: 1352
- Joined: 08 Sep 2008, 22:10
- Has thanked: 3 times
- Been thanked: 12 times
4 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 28 guests