[Devel] one more (possible) improovments of mysql module

Henning Westerholt henning.westerholt at 1und1.de
Thu Jun 21 09:15:38 CEST 2007

On Mittwoch, 20. Juni 2007, Victor Gamov wrote:
> > sorry for the late reply, i was quite busy with work.
> oh sorry for my persistence

Hello Victor, no problem. I'm persistent too. :-)

> > As i said before, fetch_result does quite a few functions calls that are
> > not needed for the normal and raw query case. So for this functions, that
> > get called a lot, the performance would decrease. Fetch_result is as
> > twice as big as store_result, is does this row counting, has some loops
> > inside. This means more code that needs to get executed, more
> > possibilities for errors..
> >
> > So i think we should stay with the current state.
> I check mysql/dbace.c and mysql/res.c once again and found following
> functions calls from db_mysql_store_result() and db_mysql_fetch_result():
> db_mysql_store_result() == db_mysql_new_result + mysql_store_result() +
> [...]
> internal_for_loop = mysql_fetch_row() + db_mysql_convert_row()

I did another more thorough review of the code, yes you're right. Both 
functions works in the quite the same way.

> So, db_mysql_store_result() uses more subfunctions calls while
> db_mysql_fetch_result() calls only really useful functions.

store_result uses convert_rows, and fetch_result does this work internally. As 
this subfunctions are inlined, the result should be comparable. 

> Now I change db_mysql_store_result() to db_mysql_fetch_result() in my
> 1.2.1  and it works fine for my config (SELECT/UPDATE/INSERT queries are
> used).  I'll try to prepare patch later at this week.

Ok, go ahead. Please do some tests of this change for trunk, preferable with 
load. The only affected functions are query and raw_query, so INSERT and 
UPDATE should be safe. You could also remove the now unneeded convert_rows 



More information about the Devel mailing list