I started to remove 'lvalue' from VALUE_PAIR, in the theory that we can use the union of data types for something else. It turns out we can't, at least until we audit the code for things that print to vp_strvalue for integer/date/ipaddr types. I've also started removing the references to "paircreate" from the server source, and replacing them with a wrapper function. It turns out that all of the calls in the core && modules did the same thing: vp = paircreate() if (!vp) OOM pairadd(...) So replacing all that with 1 line of code makes a difference. Plus, it centralizes the place where VP's are allocated (one function). It also passes the REQUEST* to that function, which lets us move to memory pools later. According to callgrind, memory free/alloc is a significant cost in the server (~15%). So fixing that will make a big difference. I plan on doing the same thing with pairmake(). Almost all of the calls to pairmake() are with fixed attribute names. So they should be replaced with calls to paircreate(), with the attribute number hard-coded in. It's a lot of repetitive grunt work, but it's laying the foundation for some useful changes in the future. I think I also have an idea for how HUP can be handled without killing the server, and without large amounts of complexity. More later, as I flesh it out. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog