[Dan..]

Quote:

Originally Posted by fordawinzz Yes, I'm using it. crashdetect: Код: [17:15:38] [debug] Run time error 19: "File or function is not found" [17:15:38] [debug] sql_connect [17:15:38] [debug] sql_query [17:15:38] [debug] sql_num_rows [17:15:38] [debug] sql_get_field_assoc_int [17:15:38] [debug] sql_get_field_assoc [17:15:38] [debug] Run time error 19: "File or function is not found" [17:15:38] [debug] sql_connect [17:15:38] [debug] sql_query [17:15:38] [debug] sql_num_rows [17:15:38] [debug] sql_get_field_assoc_int [17:15:38] [debug] sql_get_field_assoc

Use the .inc file provided in this package: https://github.com/udan11/samp-plugi...2.zip?raw=true

[fordawinzz]

# FIXED, thank you !

[maddinat0r]

Good job Dan, keep on going! Did you've done your tests on a Windows or a Linux machine?
I think I'll have to refactor most of the threading code in BlueG's/my plugin.

Quote:

Originally Posted by ****** Even just replacing the Mutex with a Critical Section will make a huge difference.

True story, already did that in BlueG's plugin (but currently not pushed to SVN). Critical Sections are almost 100 times faster than Mutexes, but unfortunately this speed improvement works only on Windows.

[Dan..]

Quote:

Originally Posted by ****** How are you doing on the lock-free containers front? Even just replacing the Mutex with a Critical Section will make a huge difference.

I still have problems with the `erase` operation. The container needs to be locked.

Quote:

Originally Posted by Pain123 Good job Dan, keep on going! Did you've done your tests on a Windows or a Linux machine? I think I'll have to refactor most of the threading code in BlueG's/my plugin. True story, already did that in BlueG's plugin (but currently not pushed to SVN). Critical Sections are almost 100 times faster than Mutexes, but unfortunately this speed improvement works only on Windows.

Your are exaggerating, critical sections are about twice as fast, not 100 times.

Код:

Critical Sections - 8546 ms
Mutexes - 14088 ms

[Dan..]

I continued working on this plugin and this are the results I achieved:

Code:

Dan - 12178 ms
BlueG - 53357 ms

So, my plugin is 4.38 times faster (previously it was just twice as fast).

I'll upload the source on GitHub soon.

[Kar]

Quote:

Originally Posted by Dan.. I continued working on this plugin and this are the results I achieved: Code: Dan - 12178 ms BlueG - 53357 ms So, my plugin is 438% faster (previously it was just 200%). I'll upload the source on GitHub soon.

stop comparing for now, wait till the new version

you're not the only one with major improvements.

[Kyle]

I'm fed up of the speed updates, seriously...

Rather than trying to win in the competition why not concentrate on features and getting it compiled properly without issues etc?!

[Dan..]

Quote:

Originally Posted by KyleSmith I'm fed up of the speed updates, seriously... Rather than trying to win in the competition why not concentrate on features and getting it compiled properly without issues etc?!

Not only my plugin has more features, but it is also faster!

[Kar]

lol it's for the fun of it

if you don't like the speed tests ignore them..

continue to do what you do Dan..

[Schocc]

Good job. Ignore the enemies who complain of milliseconds and tests

+rep

[Richie©]

Good job with the speed! I would try this if i didnt have to convert everything (all using cache exept update and insert queries) mysql related in my gm.

[TheArcher]

Quote:

Originally Posted by Kar lol it's for the fun of it if you don't like the speed tests ignore them.. continue to do what you do Dan..

LOL dude, Dan is not talking about 1 - 2 faster but it's a huge improvement. If you don't like this you are free to stop posting.

[AndreT]

Indeed, tons of fun can be had with optimizing and writing fast code, but I assume that at one point, the direct speed comparisons no longer deserve a purpose. You've written a very decent piece of software here though and I'm glad to see the PostgreSQL support!

(About the speed stuff also... I've made a heavily downsized version myself which performs about 10 times faster than the R19/R20 version of BlueG's.)

[Baboon]

So if I am right, this uses the same functions as Blue_G's?
Also can someone compile the newest version for me?
Thanks

[Dan..]

The libraries I provide are 32-bit. You'll have to replace those 32-bit libraries from (lib/mysql) with these ones. Just copy and paste them. There might be a way to link 32-bit libraries on a 64-bit Linux, but I'm not sure how.

I consider removing the explicit path to the library from the makefile.

[maddinat0r]

You should use the -m32 flag also while linking, not only while compiling.

[Slice]

Thanks Dan and Pain123, downloading the libraries and adding -m32 to the linking fixed it.

[AndreT]

I think you can,

Quote:

address The address of the cell for C/C++ programs to access. This parameter may be NULL.

(http://www.compuphase.com/pawn/Pawn_...nter_Guide.pdf, page 39)

Edit: discard this

[yanir3]

Nevermind.

[Dan..]

Quote:

Originally Posted by AndreT I think you can, (http://www.compuphase.com/pawn/Pawn_...nter_Guide.pdf, page 39)

Trust me, you can't. I argued with Zeex about the same thing. I thought that amx_addr can be NULL, but in fact it can't. SA-MP is running an older version of AMX which doesn't check if the parameter is null.