02 Nov, 2009, Skol wrote in the 1st comment:
Votes: 0
Anyone familiar with this?
It's my understanding that RoM takes all of the areas and compiles into one big string (MAX_STRING must then hold). So as your game increases in amount of rooms, mobs etc, you'll need to increase MAX_STRING. Then, MAX_PERM_BLOCK, is the largest block of perm allocated memory right?

Anyway, having issues and wondered if the MAX_PERM_BLOCK should be raised (stock is 128k, 131072 bytes).

Any help would rock, thanks guys.
02 Nov, 2009, Runter wrote in the 2nd comment:
Votes: 0
It's my understanding that MAX_STRING is simply a define for maximum size of strings in the codebase. Such as maximum size a buffer should be.

It uses it's own little memory system where it allocates one large block when the program starts and gives pieces of it away. So my guess would be that is what MAX_PERM_BLOCK is. If you're actually running out of memory inside of the constructs of this system it would be my guess that this number should be increased.

To be honest, though, in Roms I've dealt with in the past I've pretty much scrapped this and simply replaced it with new/delete or malloc/free calls.
02 Nov, 2009, Skol wrote in the 3rd comment:
Votes: 0
Yeah, I just looked at RaM fire and saw the guys had changed the memory system.

I'd love to do the same to my game if someone has a run-down on what's changed and how it's used. Memory use is definitely a place in my coding that I could use help with.

The MAX_STRING one is a compile of all areas, it gets huge ;(. The 'memory' command will show it's size and how close it is to max etc, but I'd like to change that to dynamic and then never have to look at it again heh. Heck, if someone has an overview on memory to where I could do that with all the char's as well, that'd be sweet.
02 Nov, 2009, Skol wrote in the 4th comment:
Votes: 0
Crap, found it in string.h in RaM… looks like unchanged memory use, just moved.

32 		

/*
* Memory management.
* Increase MAX_STRING if you have too.
* Tune the others only if you understand what you're doing.
*/
#define MAX_STRING 1413120
#define MAX_PERM_BLOCK 131072
02 Nov, 2009, Skol wrote in the 5th comment:
Votes: 0
It varies depending on port (my coder port has like 8 areas, stripped etc), but here's on the builder port (BP):

Strings 61459 strings of 8351257 bytes (max 9437184).
Perms 149978 blocks of 14559592 bytes.

On BP I'd had it at 8*1024*1024, which blew out again. So I raised it to 9*.
It just seems… incorrect, to have to go and do this constantly, must be a better way.
02 Nov, 2009, quixadhal wrote in the 6th comment:
Votes: 0
Yes, RaM has the files reorganized to try and decouple some of the parts that were intertwined somewhat haphazardly. There was no point in doing a different memory system, as we intended to replace strings entirely with the STL's std::string. That would allow safe and sane string handling (no strdup/strcpy messes), and for those concerned with memory usage, a shared string class could be dropped in with minimal changes.

MAX_STRING in ROM is the amount of memory allocated to the shared string pool.
02 Nov, 2009, Skol wrote in the 7th comment:
Votes: 0
Thanks quix :).
I wonder if there isn't a 'midway' type approach, as my game has been worked on since 96, I'd hate to have to patch 'it' into RaM or another base. But I wouldn't mind redoing the memory use into something more dynamically allocated. Perhaps a function to figure out used string length, then X additional…
02 Nov, 2009, David Haley wrote in the 8th comment:
Votes: 0
Of course there's a way to fix the shared string handling in RoM without completely porting to C++ or to RaM or what-have-you; but pretty much of course as well, this might not be terribly easy either and requires understanding how the memory layout works and how to deal with dynamic memory in general.
02 Nov, 2009, Skol wrote in the 9th comment:
Votes: 0
I hear you, I didn't expect it to be easy heh.
I haven't dealt with heap memory much at all unfortunately, a few spots but never something with this much reach.
02 Nov, 2009, David Haley wrote in the 10th comment:
Votes: 0
Well, basically you wouldn't do this thing in the first place, where a big block is allocated and then mucked around with. You would allocate new chunks on demand. What RoM is doing might have been relevant "a few" years ago (a few > 10, in this case) but these days just simply isn't something you should be worrying about when writing a MUD (or similar).

It's actually probably easier to manage memory this way, it's just that the conversion isn't trivial and easy to seriously muck up. (On the plus side, it's hard to mess things up subtly; if there is a mistake it is likely to fail spectacularly fairly quickly.)
02 Nov, 2009, Skol wrote in the 11th comment:
Votes: 0
Here was my most recent approach:
extern int port;

#if (port == 8662)
#define MAX_STRING 6291456 // Coder port 6x 1024*1024
#else
#if (port == 8650)
#define MAX_STRING 9437184// 9*1024*1024 (on 11/01/09)
#else
#define MAX_STRING 8388608
#endif
#endif


Unfortunately, while it does know what 'port' is, it appears to be going to the default (8388608) according to my memory function:
Quote
Ansalon Port: Coder (8662)
Affects 226
Areas 7
ExDes 263
Exits 1646
Helps 730
Socials 244
Mobs 158(158 new format)
(in use) 304
Objs 371(371 new format)
(in use) 446
Resets 731
Rooms 745
Shops 16
Ponds 18
Strings 6074 strings of 956238 bytes (max 8388608).
Perms 7897 blocks of 661408 bytes.


While I could simply increase the size, I wouldn't mind increasing it only on that specific port. Although it doesn't appear to be causing any higher memory or cpu usage with the higher rate on the lighter ports.
02 Nov, 2009, Tyche wrote in the 12th comment:
Votes: 0
You are using pre-compiler macros?
02 Nov, 2009, David Haley wrote in the 13th comment:
Votes: 0
You can't mix macros and run-time values like that. The macros are pre-processed, that is, they are processed before the code is compiled. Those if statements are not doing what you think they're doing. Is there any reason to simply not use the largest value everywhere?
02 Nov, 2009, Skol wrote in the 14th comment:
Votes: 0
Rofl, damn that's right!
Sorry, the hack in me showed there. That'd definitely be the why-fer-how-come heh.
I hear you and I'll simply use the largest.
*goes back and reads AB on C again*
03 Nov, 2009, Davion wrote in the 15th comment:
Votes: 0
Skol said:
Anyone familiar with this?
It's my understanding that RoM takes all of the areas and compiles into one big string (MAX_STRING must then hold). So as your game increases in amount of rooms, mobs etc, you'll need to increase MAX_STRING. Then, MAX_PERM_BLOCK, is the largest block of perm allocated memory right?

Anyway, having issues and wondered if the MAX_PERM_BLOCK should be raised (stock is 128k, 131072 bytes).

Any help would rock, thanks guys.


MAX_PERM_BLOCK actually has very little to do with the shared string code. It has to do with the function alloc_perm(). alloc_perm is the function called every time you allocate one of your recycled structures (affect, char_data, pc_data, etc). MAX_PERM_BLOCK limits the size of these structures (128k+ structure, wowzers :P). All alloc_perm() is, is a fancy call to 'calloc'. It'd be pretty safe to just bypass it entirely. You can change all your calls, or just do a simple hack ->

void *alloc_perm( int sMem )
{ void *mem;
if( (mem = calloc(1, sMem) ) == NULL )
{ perror("alloc_perm");
exit(1);
}

nAllocPerm += 1;
sAllocPerm += sMem;
return mem;
}


That'll do error checking, and maintain the 'memory' command.
03 Nov, 2009, Tyche wrote in the 16th comment:
Votes: 0
This article might be helpful, RomMemorySystem
03 Nov, 2009, Skol wrote in the 17th comment:
Votes: 0
Tyche said:
This article might be helpful, RomMemorySystem

Thanks on both Tyche, I'm a readin' ;).
03 Nov, 2009, Runter wrote in the 18th comment:
Votes: 0
David Haley said:
Well, basically you wouldn't do this thing in the first place, where a big block is allocated and then mucked around with. You would allocate new chunks on demand. What RoM is doing might have been relevant "a few" years ago (a few > 10, in this case) but these days just simply isn't something you should be worrying about when writing a MUD (or similar).

It's actually probably easier to manage memory this way, it's just that the conversion isn't trivial and easy to seriously muck up. (On the plus side, it's hard to mess things up subtly; if there is a mistake it is likely to fail spectacularly fairly quickly.)


QFT
03 Nov, 2009, quixadhal wrote in the 19th comment:
Votes: 0
If you really want to improve the ROM memory code without ripping it out, one small step would be to remove the hard-coded values and simply keep track of what's allocated. Unless I missed it somewhere, ROM never actually frees memory, it allocated it and then puts "unused" chunks onto a free list to be recycled. Historically, that's because malloc() and the underlying sbrk() it uses were very expensive operations, so hanging onto it yourself was faster. In the ROM implementation, strings are allocated until MAX_STRING is passed, at which point it fails. I believe MAX_PERM_BLOCK does the same for structures (as Davion said).

You could rework that so instead of failing, it emits a warning and bumps the limit up. Right now (at least in RaM), that's in db.c. Instead of pre-processor defines, you'd initialize runtime variables to some reasonable value. If you cross the limit, you'd need to allocate more space. Unfortunately, you can't use realloc(), because it won't guarentee that your memory block isn't moved, which would make all your string pointers invalid.

Soooo, changing the "string_space" variable to an array is one option. When you fill up the first block, you'd calloc() off another one as string_space[1] and all new strings would be allocated from there….
03 Nov, 2009, Runter wrote in the 20th comment:
Votes: 0
http://www.mudbytes.net/index.php?a=file...

I wrote this a year or two ago. It's similar to the rom system, can be dropped in, and uses approx how much memory is actually in use—as well as expanding automatically.

It was an interested project that you may be interested in seeing, at least.
0.0/31