In addition to clearing the event log, you need to occasionally go into your sql admin panel through the webhost and "shrink" the database. They should have a function to either "shrink" or "optimize" and you should run that on the database. You should see a decrease in the database size. I don't know why DNN doesn't have this built in, it really should be because that log file can get rather out of hand in terms of size, too. It is a separate log from the event viewer, at least as I understand it. Clearing the even log never has an effect on that database log. And it's a pain to have to always go in through the web host control panel to shrink it. I'm no sql expert, but there are scripts you can run via the host menu sql option, but I've yet to find anything easy to understand for someone not real experienced with sql. I've never taken the time to view the contents of that log that is attached to the database, I don't know if that's even possible. I just know that as far as I'm concerned it doesn't seem to be necessary as "shrinking" or "truncating" or what ever you want to call it never causes any loss of anything that has ever been needed, it just "cleans" it out and then you start all over again and have to "shrink" it again in a few weeks. Boring and tedious, but necessary ritual. You should take a look at the exceptions in the event viewer before you clear the event viewer, though, in case there are any problems being reported there that need to be attended to.
Also, make sure you have cache turned on. Go to host menu, host settings, and at the bottom of the page there is "performance settings". Set cache to moderate or heavy and that will help a lot, and it's really a noticeable difference even on a localhost development setup.
I do not use the white space filter or compression, earlier versions of dnn had serious problems with the white space and compression, it messed up site permissions and certain modules wouldn't run properly. I don't know if that has changed or been fixed or not. I've been told not to use the built in compression or white space filter in DNN because they do cause problems with certain modules and functions. Some use them with no problems, but some of us have had serious performance issues from them.
Also, I've been told to use "page' and "disk" in performance setting, not "memory". I don't remember why that was recommended, but it works great for all the sites I've set up. There is just too much to remember, a disadvantage of having such an amazing and feature rich CMS.
Another thing to remember is that most asp.net installs on a shared hosting plan will shut down your program after 20 minutes of inactivity, meaning that everything that was cached is cleared out, and the next person to visit the site will have a longer page load time while DNN starts up and loads everything into memory again. The only way to avoid that is to have hundreds or thousands of visitors to your site every day so there are never any periods of inactivity, or you can use a keep-alive service which charges for "visiting" your site and keeping it from being shut down by the asp.net service. So, for sites that aren't visited before that 20 minutes is up, the next visitor has a longer page load time.
If you do want to use compression, there is a product from Snapsis called PageBlaster that has worked really well for me up through DNN 4.6.2. Have not tried it with 4.7.0 yet. They do a much better job of compression, you'll see significant decrease in page load time, and they have a paid and a free version. It surpasses the built in functions of dnn by far. If you use captcha, though, you do want to add the captcha image or module that contains it to the exclusion filter in the PageBlaster.config file. PageBlaster is really an amazing product, I wouldn't want DNN without it, they should just buy the company out and incorporate it into DNN by default, it's just a really amazing add-on.
Hope at least some of this is of help to you,
Rick