Lock / Unlock Scroll

Quote:

Originally Posted by Timlock You are right that T-SQL May be faster in small amounts, however you are not taking in to consideration by modifying vsro stored procedures you are adding a workload every time those procedures are called which in turn adds nanosecond delays to every gameserver / shardmanager function that calls on them. Especially logging procedures.

Yes, there is a nanosecound delay everytime if this procedure is called

compared to a packet filter:
there is a nanosecound delay on EVERY packet send from Client > Server :)

this procedure is maybe called one time while the packet filter recived like 500 packets at this time.

MOVE_ITEM= is used whenever you move an item in the inventory (your inventory, pet and storages)
DEL_ITEM= is used whenever you drop / sell / use the last stack of an item
P2P= is used on exchange and stall

compared to:
move packets, pings, select monster bla bla way tooooo much

Quote:

Originally Posted by Syloxx Yes, there is a nanosecound delay everytime if this procedure is called compared to a packet filter: there is a nanosecound delay on EVERY packet send from Client > Server :) this procedure is maybe called one time while the packet filter recived like 500 packets at this time. MOVE_ITEM= is used whenever you move an item in the inventory (your inventory, pet and storages) DEL_ITEM= is used whenever you drop / sell / use the last stack of an item P2P= is used on exchange and stall compared to: move packets, pings, select monster bla bla way tooooo much

Nope, there is a switch in every packet sent to the filter it's not like counting delays. It's delayed once and it beats me if any server is not using one by now so it makes no difference.

Quote:

Originally Posted by Syloxx Yes, there is a nanosecound delay everytime if this procedure is called compared to a packet filter: there is a nanosecound delay on EVERY packet send from Client > Server :) this procedure is maybe called one time while the packet filter recived like 500 packets at this time. MOVE_ITEM= is used whenever you move an item in the inventory (your inventory, pet and storages) DEL_ITEM= is used whenever you drop / sell / use the last stack of an item P2P= is used on exchange and stall compared to: move packets, pings, select monster bla bla way tooooo much

its much more than just 1 ns.

#1. The SQL overhead is huge, especially the serialization itself already takes longer.

#2. SQL Server has a limited number of worker threads. 704 exactly with 16 cores on 64bit systems.

Now guess how many queries get executed. Now what happens if a worker has to wait until previous shit is done?

Now guess what happens if shit starts getting queued?

Now guess what happens when there is additional waiting and idle time when waiting for HDD and so on?

You can't just go and generalize everything ESPECIALLY when you dont even know how the SQL server works.

Writing some SQL.. every 12yo kid can learn that.
Writing good performant SQL, quite a lot of people can do that.
Making SQL Server behave performant, only a few of the above can do that.

Go and spend time to figure out how shit actually works, then you can talk about performance again.

PS: Just the fact that it runs synchronous on these days hardware slows shit down.

Quote:

Originally Posted by Royalblade* its much more than just 1 ns. #1. The SQL overhead is huge, especially the serialization itself already takes longer. #2. SQL Server has a limited number of worker threads. 704 exactly with 16 cores on 64bit systems. Now guess how many queries get executed. Now what happens if a worker has to wait until previous shit is done? Now guess what happens if shit starts getting queued? Now guess what happens when there is additional waiting and idle time when waiting for HDD and so on? You can't just go and generalize everything ESPECIALLY when you dont even know how the SQL server works. Writing some SQL.. every 12yo kid can learn that. Writing good performant SQL, quite a lot of people can do that. Making SQL Server behave performant, only a few of the above can do that. Go and spend time to figure out how shit actually works, then you can talk about performance again. PS: Just the fact that it runs synchronous on these days hardware slows shit down.

+1

Quote:

Originally Posted by Royalblade* its much more than just 1 ns. #1. The SQL overhead is huge, especially the serialization itself already takes longer. #2. SQL Server has a limited number of worker threads. 704 exactly with 16 cores on 64bit systems. Now guess how many queries get executed. Now what happens if a worker has to wait until previous shit is done? Now guess what happens if shit starts getting queued? Now guess what happens when there is additional waiting and idle time when waiting for HDD and so on? You can't just go and generalize everything ESPECIALLY when you dont even know how the SQL server works. Writing some SQL.. every 12yo kid can learn that. Writing good performant SQL, quite a lot of people can do that. Making SQL Server behave performant, only a few of the above can do that. Go and spend time to figure out how shit actually works, then you can talk about performance again. PS: Just the fact that it runs synchronous on these days hardware slows shit down.

OK, menzz me fyll noob me no gnow whad berformanze is... ;(

Looks like you forgot one big thing

all the procedures get executed ANYWAY, all we have to do is add a simple IF EXISTS IN check :)

good job

Quote:

Originally Posted by Syloxx OK, menzz me fyll noob me no gnow whad berformanze is... ;( Looks like you forgot one big thing all the procedures get executed ANYWAY, all we have to do is add a simple IF EXISTS IN check :)

Every time you add another Query to a procedure, it slows it down even more.

Procedure editing is horrible, especially if you have one that looks like

IF
IF
IF
IF
IF
IF
etc...

The sql server has to run a query check for each if/elseif EVERY time the procedure is called, which with vsro files is ALOT of times.... with 1000+ players you can call the procedure more then 500 times a second... and if your delay is more then 1MS... your whole server will lag.

Not to mention what akasch said, there are only so many threads available to a sql instance. which makes things worse.

Quote:

Originally Posted by Chiliad Every time you add another Query to a procedure, it slows it down even more. Procedure editing is horrible, especially if you have one that looks like IF IF IF IF IF IF etc... The sql server has to run a query check for each if/elseif EVERY time the procedure is called, which with vsro files is ALOT of times.... with 1000+ players you can call the procedure more then 500 times a second... and if your delay is more then 1MS... your whole server will lag. Not to mention what akasch said, there are only so many threads available to a sql instance. which makes things worse.

ever heared from

IF
ELSE IF
ELSE IF
ELSE IF
ELSE IF
etc?

or CASE? ;)

and yes, if a egypt modify these procedures then yes... it might be a bad idea but if i do it it will just be fine :P

and what akasch said is true, but this procedure have to execute it anyway so procedure + any outsourced program is still slower then procedure with an additional if check.

thanks i add

Keep it up ;)

Quote:

Originally Posted by Syloxx ever heared from IF ELSE IF ELSE IF ELSE IF ELSE IF etc? or CASE? ;)

Oh yes, thats soooo much better... solves every issues, so fast it subtracts time...

/SARCASM

Quote:

Originally Posted by Chiliad Oh yes, thats soooo much better... solves every issues, so fast it subtracts time... /SARCASM

/ANTI-SARCASM

Actually it does shorten the time xD ELSE will terminate the check once a condition is met! On the other hand, IF,IF,etc will keep checking all of them even if one of the conditions was validated already to be true.