From: David E. <de...@ss...> - 2002-06-13 19:39:46
|
> 2. jlatour suggested using LIMIT 1 for SELECT statements that > expect only one row as a result. This will allow MySQL to > return after finding the first row and it will also allow > MySQL to predict the size of the SQL query results and hence > execute faster. I have often used LIMIT statements in my PHP/MySQL programs, but I'm wondering if this is a good idea given the future goal of database abstraction? Oracle and other databases don't support the LIMIT statement so would we end up losing it later? I suppose it depends on how the database abstraction is developed and whether we'll be able to use each databases custom features for optimization of each type of backend. I guess abstraction is still a long way off, though, so maybe the performance gain is worth it in the short term. Just a thought. David |
From: John S. H. <jhu...@va...> - 2002-06-13 19:54:43
|
Hey Ken, How soon can you dump the data from the demo Mantis for use as a large set of data? I have my test setups in place and ready to tweak. John ************************************** John Huggins VANet jhu...@va... http://www.va.net/ ************************************** |
From: Kenzaburo I. <ke...@30...> - 2002-06-13 20:41:58
|
I'll get the sf data up tonight. pconnects should be optional. If I recall correctly it's been historically buggy and, as noted, don't always scale well. It seems like the speed slowdown was also when we started doing left joins, etc. Is it reasonable to think that splitting these into simple queries and processing them in PHP might be faster? Probably will want to test this. Feel free to checkin debug code/files. We'll just need to remember to remove them later before release. And thanks to everyone for chiming in. I really appreciate it. Thanks, -Ken > How soon can you dump the data from the demo Mantis for use as a large set > of data? I have my test setups in place and ready to tweak. > > John |
From: Victor B. <vb...@op...> - 2002-06-13 22:10:04
|
Hi, > pconnects should be optional. If I recall correctly it's been historically > buggy and, as noted, don't always scale well. I found out that in core_API.php the database is opened and closed to retrieve the language from the user's preferences, hence, a database is opened/closed three times per page!!! I will be making a change where the database will be opened once in core_database_API and no where else. It will be automatically closed at the end of each page. While doing that I will add the option to use pconnect. > Feel free to checkin debug code/files. We'll just need to remember to remove > them later before release. Unless there is a good reason to check in debug code, I think we should avoid it. We should aim at having our CVS at a state where it is easy for people to download and use with minimal overheads / risks. We are developing a lot of new features and a lot of Mantis users might decide to upgrade and do some testing in order not to wait for 0.18.0. They shouldn't need to modify the code to remove debugging work. Regards, Victor. |
From: Kenzaburo I. <ke...@30...> - 2002-06-14 03:57:23
|
Updates on timings. I'm working on the unaltered sf dump. The vast majority of the time is spent in printing out the reporter and handler lists. From my timings it's ~80%. Time to get busy =) Thanks, -Ken |
From: Kenzaburo I. <ke...@30...> - 2002-06-14 04:02:54
|
Ok, commented out the calls to the two user option list printing functions and now the speed on sourceforge is down to less than 3 seconds. -Ken > Updates on timings. > > I'm working on the unaltered sf dump. The vast majority of the time is > spent > in printing out the reporter and handler lists. From my timings it's ~80%. > > Time to get busy =) > > Thanks, > -Ken |