VB type comments

[Tyris]

ok, thanks a heap ^_^ I think I'll probably ditch the pre-parse then... its just a stack of extra code... I'm gonna be remodelling the system I'm working on quite a bit this weekend.
Thanks

[writeto]

That was probably the worst phrased question I have asked in a while.
My question was :
Have you tested a topic with say 100 large posts? Does that slow the process down a lot?

Yeah I think 9.75 mb is a pretty large post... That is larger then I would have expected.

Let me explain my reply :
Although I prefer to do all my file handling (including database) in one area
This is preferrable if you are doing a very small set amount of file handling/databases quering.

but this simply can not be done if I have 100,000 items in the database.
It is not efficient by any means to read/do a lot of file reading/database quering as you have to store all this information.

This is why I will never be a professor...

Andrew

[[Unknown]]

Nah, the size of the data returned can effect load, but not a *whole* lot.
PHP buffers the queries.....

Err, you mean 9.75 kilobytes - which is still huge.

Well, all the data handling is done before the stuff goes to the templates.... but, I've always *felt* (very subjectively...) that "spreading out" queries a small bit helps reduce load... but like I said, in reality it's so quick it doesn't hardly matter.

-[Unknown]

[writeto]

Gee that is only 9.75 MB... I don't know why I thought that said KB.

I still have to disagree with you on the data handling, it is true that when working with small databases, but I have dealt with databases upwards from 1.25 - 5MB of pure text. Both instances were in accounting instances. Had I attempted to read all of the data necessary for processing in at one time I would have had a huge hash table and it would have been slow. I suppose if you are dealing with strictly with top of the line processors with an abundance of ram this may not be the case but it isn't safe to assume that.

This is speaking in general and not limited to SMF*  as for their purpose it would be unrealistic to expect a single topic to be that large.

Another question:

Is it your upload script that is limited to 10000 bytes (does it time out?) or is it a set limit?

Andrew

*edited to reflect the truth

[[Unknown]]

No it's a set limit.  Nothing to do with upload.

If you're just storing that data, it only goes into ram.  If you're talking about megs of data at a time, there's obviously something wrong with your database/table model.  You should never have to deal with that much data - that's what the database is for.  Proper use of keys will mean that it won't matter how much information there is or isn't.

And it's SMF not SMB .  A forum is a place where peopel can talk, which contains categories and boards.  Boards are specific subjects of discussion.

-[Unknown]

[writeto]

Well to articulate further why I was using that much data at one time:

The project was used to analyze theft patterns and to maximize productivity by analyzing the amount of money taken in over a period of 2 years in 30 minute intervals. It was quite necessary to access all of the data for a given set of time. One of the databases had 22 or 23 tables, 15 of which required processing for the algorithm given to us. It was a mess and slow but it worked. Not to mention that it was an Access database (which we had no control over as we had not created the original software).

Andrew

[Slonarch]

Getting back to the topic: I was a user of a forum with such feature for 3 years, and now on forums without it  I feel like I am missing a finger. Actually, in mosts cases you can decide wether to read a topic or not with it, and it saves a lot of time and bandwith.

[[Unknown]]

Well, it definately doesn't save bandwidth, sorry, to load most of the first post for the 20 topics shown on the screen... .

Anyway, I've already described (in Tips and Tricks) how to do this with SMF.

-[Unknown]

[Slonarch]

OK, thanks for the link. In fact, I was deciding what board to use, and that was the only feature I regard as "very important" that SM lacked, so the decision is made now