So, I''m personally cool with this change (patch from #5454, applied in [4596]), and I''ll make it work for Oracle tomorrow. But just wondering if folks considered the performance impact of the change? From a simple test it seems that BigDecimal math is about twice as slow as using Floats.
On Jul 8, 2006, at 11:00 PM, Michael A. Schoen wrote:> But just wondering if folks considered the performance impact of > the change? From a simple test it seems that BigDecimal math is > about twice as slow as using Floats.BigDecimal is slow, but numeric(10,3) ought to be meaningful. Anyone tried LongDecimal? http://rubyforge.org/projects/long-decimal jeremy
On 7/9/06, Jeremy Kemper <jeremy@bitsweat.net> wrote:> On Jul 8, 2006, at 11:00 PM, Michael A. Schoen wrote: > > But just wondering if folks considered the performance impact of > > the change? From a simple test it seems that BigDecimal math is > > about twice as slow as using Floats. > > BigDecimal is slow, but numeric(10,3) ought to be meaningful.It appears to still use floats for ''float'' columns, does oracle not have one?> Anyone tried LongDecimal? http://rubyforge.org/projects/long-decimal-- Cheers Koz
On Sat, Jul 08, 2006 at 11:00:08PM -0700, Michael A. Schoen wrote:> But just wondering if folks considered the performance impact of the > change? From a simple test it seems that BigDecimal math is about twice > as slow as using Floats.As one of the main authors of the patch, I did test this, and found this, and tried hard to ensure there wasn''t any stupidity getting in the way of usage of BigDecimal (see for example the example in the Ruby stdlib for BigDecimal, which creates N new BigDecimals instead of lifting the constant out of the loop). With the stupidity, on a worst case (tight loop, with string to BigDecimal conversions every time), there''s a 110% slowdown. With the stupidity cleaned up some, it''s much lighter (50% or so), and conceivably less after BigDecimal gets cleaned up a bit more (I''m working on a patch for Ruby BigDecimal itself still). However more significantly, unless you mis-read the patch, :float is NOT replaced with :decimal. It''s merely supplemented. Using :float still gets you the same old behavior in Rails. -- Robin Hugh Johnson E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Michael Koziarski wrote:> It appears to still use floats for ''float'' columns, does oracle not > have one?Not really. Oracle uses "NUMBER" for all numeric columns. There''s also a "FLOAT" type, but it''s not typically used (and it''s effectively the same as NUMBER). In my patch to make this work for Oracle I''ll make NUMBER (w/ no precision or scale) translate to :float.
Robin H. Johnson wrote:> However more significantly, unless you mis-read the patch, :float is NOT > replaced with :decimal. It''s merely supplemented. Using :float still > gets you the same old behavior in Rails.Oracle doesn''t really have a FLOAT or DECIMAL datatype, it''s all NUMBER. I''ll get the OracleAdapter to work with this tonight.
Michael A. Schoen wrote:> Michael Koziarski wrote: >> It appears to still use floats for ''float'' columns, does oracle not >> have one? > > Not really. Oracle uses "NUMBER" for all numeric columns. There''s also a > "FLOAT" type, but it''s not typically used (and it''s effectively the same > as NUMBER). > > In my patch to make this work for Oracle I''ll make NUMBER (w/ no > precision or scale) translate to :float.This seems a good example of a situation where Rails needs its own (optional) mapping metadata. One application may specify storage of a NUMBER with high precision, wanting to do floating-point calculations with it, whereas another application might need to treat similarly-specified NUMBERs as BigDecimal. regards Justin Forder