[maddinat0r]

Quote:

Originally Posted by KyleSmith Is it possible to speed up mysql_real_escape_string? It takes 193ms for me for about 600 length string. I'm using R30.

It's not so easy to improve the escaping speed, but I'll see what I can do.

Quote:

Originally Posted by AndreT I think I see a potential problem with the code in CScripting.cpp. The memory allocated for the output of the C mysql_real_escape_string must be (2*strlen(input))+1. Assuming that you usually know what you're doing, when you write PAWN code, you do this: pawn Код: new src[32]; new dest[64]; mysql_real_escape_string(src, dest); // max_len=sizeof(destination) by default What the plugin native then does is: pawn Код: size_t DestLen = (params[4] <= 0 ? 8192 : params[4]); // DestLen becmes 64 (in our case at least) // ... char *StrBuffer = (char *)malloc(DestLen*2+1); // Allocates 64*2+1=129 bytes of memory memset(StrBuffer, 0, DestLen*2 + 1); // Set it all to zeros (?) cell StringLen = (cell)mysql_real_escape_string(ConnPtr, StrBuffer, Source, strlen(Source)); StrAmx::SetCString(amx, params[2], StrBuffer, params[4]); free(StrBuffer); Also, I think that memset needn't be used here - the C mysql_real_escape_string appends a NULL byte by itself. To allocate 64+1 bytes of memory (aka. what we need here to be on the safe side), it needs to make use of the SourceLen variable (cannot exceed 32 in our example) and double it and add 1 byte for the NULL. I assume this is not going to make a relevant speed difference, and perhaps the AMX interactions with large arrays is just slow, but using heap allocation (alloca instead of malloc) is a possibility here as well. Once again may not make a relevant speed difference, and may even be dangerous (if you start allocating megabytes!)

Looks like I already saw that problem while developing R33, the current code is already using the length of the source string.
Yes, it looks like the library's mysql_real_escape_string appends a NULL-byte, didn't saw that. This indeed saves me the use of memset, thanks for pointing that out.

Quote:

Originally Posted by AndreT I assume this is not going to make a relevant speed difference, and perhaps the AMX interactions with large arrays is just slow, but using heap allocation (alloca instead of malloc) is a possibility here as well.

I think you meant stack allocation instead of heap. Using stack allocation instead of heap decreases performance by ~6.29%.

Quote:

Originally Posted by Misiur Hi guys, last time (R8 ) there were some issues with mysql_format and linux - is this fixed now?

I completely rewrote mysql_format in R28 and tested it on Linux, I doubt that there are any problems now.