[Leonardo]

Originally Posted by Michalplyoutube tf2itemsinfo is better and deal with it

popular != better

[Erreur 500]

Originally Posted by Powerlord I already suggested rewriting TF2ItemsInfo to have it write to a SQLite database when the server starts.

I think it's a good idea!
When the server starts TF2II, it detect if the DB is up to date (by checking TF2 version). If it isn't the case, TF2II scan tf2_items.txt and update DB. It may take some seconds to create/update the DB, but this will be done when server start (no player connected). When it is done, each plugin will be able to use TF2II included commands, and TF2II will ask the DB to answer.
Nothing change for plugins which use TF2II.

PROS : More performance + less RAM needed, excepted when the server starts AND DB need to be updated (There is more RAM available when there is no player) + DB only update when TF2 version change.

CONS : When Valve update TF2, servers will take more time to start.

I think I can modify TF2II to due that.

[Potato Uno]

Originally Posted by Michalplyoutube But who uses it > Nobody besides friagram I haven't seen any plugin using it and its outdated last update was since 2013 tf2itemsinfo is better and deal with it

Someone is butthurt.

TF2ItemsInfo is also outdated and the only "updates" it got are hacks from random people that only make the problem worse.

The fact is, this plugin sucks and no respectable server owner should run it if they don't want their server to randomly freeze in the middle for several seconds. That and Michell already pointed out some performance problems with the reloader. The only correct way to handle it is to attack the root of the problem itself. This plugin sounds like a case of the XYProblem to me.

As for rewriting TF2ItemsInfo to use a database, that would work but if every call to the item schema requires an SQL query then wouldn't that be horiffically slow? (O(N) search each time.) Plus you would have to make sure that the current "API" that TF2ItemsInfo provides still works (i.e correct output redirection).

Maybe it's possible to redirect all TF2ItemsInfo calls to Friagram's extension? Where if you call a function it just searches the data in Friagram's extension? (Would that even be allowed?)

[Chdata]

Originally Posted by Michalplyoutube But who uses it > Nobody besides friagram I haven't seen any plugin using it and its outdated last update was since 2013 tf2itemsinfo is better and deal with it

I was posting it in response to someone else asking about it.

No need to get an attitude over it.

[Michalplyoutube]

Originally Posted by Potato Uno Someone is butthurt. TF2ItemsInfo is also outdated and the only "updates" it got are hacks from random people that only make the problem worse. The fact is, this plugin sucks and no respectable server owner should run it if they don't want their server to randomly freeze in the middle for several seconds. That and Michell already pointed out some performance problems with the reloader. The only correct way to handle it is to attack the root of the problem itself. This plugin sounds like a case of the XYProblem to me. As for rewriting TF2ItemsInfo to use a database, that would work but if every call to the item schema requires an SQL query then wouldn't that be horiffically slow? (O(N) search each time.) Plus you would have to make sure that the current "API" that TF2ItemsInfo provides still works (i.e correct output redirection). Maybe it's possible to redirect all TF2ItemsInfo calls to Friagram's extension? Where if you call a function it just searches the data in Friagram's extension? (Would that even be allowed?)

That would take even more time to redirect calls

[Potato Uno]

Originally Posted by Michalplyoutube That would take even more time to redirect calls

Not really.

You pass in parameters to function 1 (TF2ItemsInfo), and function 1 passes those parameters (with or without modification) to function 2 (Friagram's extension).

The worst performance hit is +1 stack frame created per function call, and maybe also parsing Friagram's extension output to something that plugins that use TF2ItemsInfo expect as a return value.

You have an input (parameters to a function call) and output (return value), so the middle can be anything essentially.

Or rewrite TF2ItemsInfo from the ground up.

[Powerlord]

Originally Posted by Potato Uno Someone is butthurt. TF2ItemsInfo is also outdated and the only "updates" it got are hacks from random people that only make the problem worse. The fact is, this plugin sucks and no respectable server owner should run it if they don't want their server to randomly freeze in the middle for several seconds. That and Michell already pointed out some performance problems with the reloader. The only correct way to handle it is to attack the root of the problem itself. This plugin sounds like a case of the XYProblem to me. As for rewriting TF2ItemsInfo to use a database, that would work but if every call to the item schema requires an SQL query then wouldn't that be horiffically slow? (O(N) search each time.) Plus you would have to make sure that the current "API" that TF2ItemsInfo provides still works (i.e correct output redirection). Maybe it's possible to redirect all TF2ItemsInfo calls to Friagram's extension? Where if you call a function it just searches the data in Friagram's extension? (Would that even be allowed?)

I haven't checked how SourceMod implements SQLite, but generally its an in-process database. You could probably test its performance by measuring how quickly the clientprefs extension can fetch data as it uses SQLite by default.

[bottiger]

As I have already said before, every modern OS caches file system reads in memory.

If you think everything with "SQL" is O(N) you have a lot to learn about programming.

[Chdata]

I don't even know what O(N) means exactly '`'

[Powerlord]

Originally Posted by Chdata I don't even know what O(N) means exactly '`'

You've never heard of Big O Notation? It's a representation of how long it takes to do something, usually involving n where n is the number of items involved.

O(1) is constant time, O(log n) is logarithmic time, O(n) is linear, O(n²) is quadratic, etc... The ones I've listed are from shortest to longest btw.