View Single Post
Unread 19 Apr 2006, 01:10   #7
Banned
Banned
 
Banned's Avatar
 
Join Date: Jul 2003
Location: ******
Posts: 2,326
Banned contributes so much and asks for so littleBanned contributes so much and asks for so littleBanned contributes so much and asks for so littleBanned contributes so much and asks for so littleBanned contributes so much and asks for so littleBanned contributes so much and asks for so littleBanned contributes so much and asks for so littleBanned contributes so much and asks for so littleBanned contributes so much and asks for so littleBanned contributes so much and asks for so littleBanned contributes so much and asks for so little
Re: New Fast Dump Processing Code

Quote:
Originally Posted by Shyne
My current applications will only have interest in the latest tick. I do obviously see the use of a history table, but perhaps would need to investigate the best way of doing so.
I don't actually use it for much in the way of history stuff. I do occasionally look up the old information. Plus I have a command for our IRC bot that shows score gained in the last 72 ticks. (So at worst the bot needs the last 72 ticks).

Quote:
A 4.4m row table might be rather slow - but having never used one, I'll leave it to you to comment

I heard that sandman says flatfile storage would have made his site faster than the current mysql site, but that may be untrue.
Flatfile will always be faster than a database application if you write the code right. With that said, the main bottleneck on our bot's speed is the IRC connection, which it throttles pretty heavily to avoid getting thrown off. I've occasionally run into problems when designing queries, but with the right indexes and structurings it's not a big deal.
Banned is offline   Reply With Quote