| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- memory allocated with spprintf, or likes, outside of mysqlnd's
allocator functions should not be freed by the mysqlnd's allocator
(a wrapper around emalloc/malloc).
- memory allocated by the mysqlnd's allocator should only be freed
by it.
- add a mode to track memory usage (malloc/free)
|
| |/
|
|
|
|
|
|
| |
with mnd_ and vice versa.
Added mnd_pestrndup and mnd_pestrdup, which wrap the normal
calls to be able to track this calls.
Fixed some failing tests.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
due to problems on windows, which were not debugged. Better have
code that is disabled not in the core.
|
| |
|
|
|
|
| |
on a upper level and by offloading it we reduce the complexity of
the core.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Memory usage optimisation. mysqlnd is not libmysql. mysqlnd does use the
Zend allocator, which means that is easier to hit memory_limit if you
have big stored (buffered) result sets. Before with libmysql you won't
hit memory_limit because libmysql uses libc's allocator and nothing is
checked. Now, with mysqlnd the situation is stricter and it is easier to
hit memory_limit. We try to optimize for big result sets. If a result set
is larger than 10 rows we will start freeing some data to keep memory usage
after 10 rows constant. This will help in the cases where a buffered result
set is scrolled forward only and just only once, or mysqlnd will need to
decode data from the network buffers again - yes, it is a trade-off between
CPU time and memory size. The best for big result sets is of course using
unbuffered queries - for comparison : 3 Million rows with buffered take
at least 180MB, with buffered you will stay at 3MB, and unbuffered will be
just 7-8% slower.
|
| |
|
|
|
|
|
|
|
|
|
| |
Fix a bug with mysqlnd_fetch_field(_direct()). With mysqlnd the optimised
function was called, which however, doesn't respect that during store the
raw data is not unpacked, to be lazy. The data is unpacked to zvals later,
during every row fetch. However, this way max_length won't be calculated
correctly. So, if a mysqlnd_fetch_field(_direct) call comes we need to
unpack everything and then calculate max_length...and that is expensive,
defies our lazy unpacking optimisation.
|
| | |
|
| |
|
|
|
| |
startup)
|
| | |
|
| |
|
|
|
|
| |
Get rid of many defines (which simplifies the code a lot),
as well as uint->unsigned int
|
| |
|
|
|
|
|
|
| |
- More statistics
- Fixed endless loop - mysqlnd_stmt_next_result() returned FAIL but as it
is defined to be 1 (and PASS is 0), checking for mysqlnd_stmt_more_result()
was successful although we were expecting a FAIL.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
Patch ext/mysql and ext/mysqli to support mysqlnd
|
