Rocks'n'Diamonds 4.3.0.0 Release Candidate 2 released!

R'n'D is always evolving. Check here to see if a new version is out.

Moderators: Flumminator, Zomis

User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Rocks'n'Diamonds 4.3.0.0 Release Candidate 2 released!

Post by Holger »

OK, found and fixed that hair-raising bug (which was a stupid, noob-style pointer bug -- I should have know better when I wrote that crap)! And did another test run with my 610 tapes, and had the same number of open file descriptors after the upload.

RC5 is on its way... :roll:
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: Rocks'n'Diamonds 4.3.0.0 Release Candidate 2 released!

Post by filbo »

Heh. I was gonna say, I have some questions about the fate of sockets 'udp' and 'sfd' in network.c:ConnectToServer(), but I don't _think_ those are the cause, because I doubt that would be getting called in every upload. (It's about setting up networked play, not the networked global score / tape repository...)
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Rocks'n'Diamonds 4.3.0.0 Release Candidate 2 released!

Post by Holger »

I was gonna say, I have some questions about the fate of sockets 'udp' and 'sfd' in network.c:ConnectToServer(), but I don't _think_ those are the cause, because I doubt that would be getting called in every upload.
No, it's completely unrelated code.
Then there's a subdirectory of tapes for each level -- not so good. On my filesystem (ext4), directories are 4KiB even if they only have one file inside. The files within are more like 1K each, so this is a 5:1 bloating of the storage.
I am still not happy with the current "code the level number into the score tape filename" solution (as I use that score tape filename -- without level number -- at some other places, as mentioned, and I prefer to have it everywhere the same), and I think I will revert that change back to the previous file system layout of having a level number directory for all score tapes (even if it is only a single file in many or even most cases).

The "5:1 bloating" is also not correct: If you count 4 KiB for a directory (inode size on most systems), you also should count a 1 KiB sized tape file as 4 KiB, as it also uses one complete inode of that size. So we then have 2:1 instead when comparing both variants. (And IMHO it would make more sense to compare "score for level X saved" with "no score for level X saved", which means that "score for level X saved" adds score file, tape file and tape file directory in one case (3 inodes), while it adds score file and tape file (without tape directory) in the other case (2 inodes), making up a 3:2 ratio, or 1,5:1, which is even less bloat.)

When comparing this with a usual 1 TB disk drive, this would be 4 MB extra space for 1000 score tapes for the "bloaty solution", or 0,0004 % of disk drive capacity. Even if you take 10'000 solved levels, this would be only 40 MB, or 0,004 %. (Even with devices like Android phones with small storage like 64 GB, this would still be less than 0,1 % of wasted disk space.)

I think I feel comfortable with wasting this for a cleaner and more future-proof file system layout. :-)
Post Reply