On May 15, 11:17 am, Hongli Lai <[EMAIL PROTECTED]> wrote: > Here's an update. I noticed that using prepared statements will indeed > make MySQL queries a bit slower. The unit tests in an unmodified Rails > edge source tree took 18 seconds. After adding prepared statements, > they took 28 seconds. I've been working on optimizing this since > yesterday evening, and I succeeded. > Using prepared statements is only advantageous in MySQL if the > arguments are large (i.e. uploading a large image), so the code will > now fallback to _not_ using prepared statements if it detects that no > argument is larger than 32 KB. The unit tests now take 18 seconds > again, thus eliminating the performance problem entirely. Something > similar can be implemented in other adapters. > > It noticed this comment in activerecord/test/binary_test.rb: > # Without using prepared statements, it makes no sense to test > # BLOB data with SQL Server, because the length of a statement is > # limited to 8KB. > # > # Without using prepared statements, it makes no sense to test > # BLOB data with DB2 or Firebird, because the length of a statement > # is limited to 32KB. > So it does make sense to add support for prepared statements in Rails.
And I forgot to say this in my last email. Before I added the fallback code, I implemented a cache for compiled prepared statements. The cache hit rate is 65%, but it resulted in no noticeable performance improvement, at least on MySQL. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
