Also posted at the UBB support forums,
here .
"Until you start thinking in terms of hashes, your aren't really thinking in Perl." -
Programming Perl, 2nd Ed., O'Reilly Books
Here's another speedup I stumbled upon, and much like the GetUserNumber speedup, I can't believe I didn't realize it earlier. This one is for the OpenProfile subroutine of ubb_lib.cgi, and operates on much the same concept of the GetUserNumber speedup, the difference being that is stores a hash of profile arrays instead of a hash of user numbers. The modification is deceptively simple for the speed increase it can give.
First off, you'll need to open up cp.cgi and ultimatebb.cgi and add
%UserProfile to the list of variables in the
use vars qw(...); string near the top of each file. Then, open up
ubb_lib.cgi and find the following:
[/code]Right under that add:</pre></div></div>Then, at the end of that subroutine find:<div class="ubbcode-block"><div class="ubbcode-header">Code</div><div class="ubbcode-body ubbcode-pre" ><pre>
So, what does this do? Well, it creates a global hash table of references to anonymous arrays. Each of these anonymous arrays contains the profile of some user, and the references to them are indexed by that user's member number. Whenever OpenProfile is called, it first checks to see if it has already read that profile from the file before, and if so, it grabs the reference to the anonymous array holding that profile, dereferences it, and passes it back to the calling function. If the profile hasn't already been read, it reads the profile array from the member's file as normal, and then stores a reference to an anonymous copy of that array in the hash table before returning it.
OK, now that we've got that settled, why is it any faster? Well, as you may or may not know, disk access is a relatively slow process compared to memory access. Any time you can access something out of memory as opposed to off of a disk, you should. This speedup stores profiles in memory after they've been read from the disk, and reads them back from the memory if they're already there. Say, for example, you have a thread where three people are participating in a conversation. One person has three posts on the thread, another two, and the last only one. Generating this thread would normally require six file accesses, whereas with this speedup it only requires three. This is just a simple example, as the OpenProfile subroutine is used all over the place in the code (50+ occurrences in Beta 7.7), and the savings can be much more significant, depending on the circumstances.
Here's hoping this makes it into the final release.
