On Wednesday, August 24, 2016 at 6:50:58 AM UTC-7, Bruce Steedman wrote: > > First off, I'm a huge fan of Sequel, big thanks to JE for maintaining such > a fabulous library. > > So, I am trying to profile memory use in my Padrino app, using the > derailed_benchmarks <https://github.com/schneems/derailed_benchmarks> > gem. This in turn uses the memory_profiler > <https://github.com/SamSaffron/memory_profiler> gem for some commands. > > Static memory allocation profiling works fine, but when I try to profile > objects > created at Require time > <https://github.com/schneems/derailed_benchmarks#objects-created-at-require-time> > I > get an error like this from this line > <https://github.com/SamSaffron/memory_profiler/blob/master/lib/memory_profiler/helpers.rb#L28> > : > > undefined method `name' for #<Sequel::SQL::Identifier @value=>:class> > (NoMethodError) > > At first I thought I must have named a database table or row 'class', but > I haven't. Upon investigation it appears to be the result of calling the > :class method on an instance of Sequel::SQL::VirtualRow. Calling puts on > the same object yields: > > `puts': can't convert Sequel::SQL::VirtualRow to Array > (Sequel::SQL::VirtualRow#to_ary gives Sequel::SQL::Identifier) (TypeError) > > I see from the docs > <http://sequel.jeremyevans.net/rdoc/classes/Sequel/SQL/VirtualRow.html> that > these objects do indeed have most methods stripped - hence the unexpected > behaviour calling :class on it. So my questions are: > > 1. Am I doing something wrong to have these rather hazardous objects > instantiated in my app? > 2. Can I prevent them from being created - or at least exposed in this > way? > 3. If answer is 'no' to 2., can the :class method be retained in these > objects? > > If 2. and 3. draw a blank I'll have to suggest a patch to the maintainer > of memory_profiler to prevent reliance on an object's :class method. > > *Using* > Ruby 2.3.1 > Sequel 4.32 > derailed_benchmarks 1.3.1 > memory_profiler 0.9.6 > > Any help much appreciated. > > Bruce >
I'm not sure how derailed_benchmarks/memory_profiler works. If it is calling arbitrary methods defined in Object/Kernel on all newly created objects, well, it's gonna have a bad time with anything subclassing from BasicObject and not Object. 1) You aren't doing anything wrong (I'm guessing, you didn't post your code or a backtrace) 2) No, virtual row use is normal in Sequel. I'm not sure how/if Sequel is "exposing" the objects. 3) You'd have to add a BasicObject#class (or Sequel::BasicObject#class) method, and I'm not sure how to write such a method without a C extension, fiddle, FFI, or including Kernel. This is probably a bug/limitation/design issue with derailed_benchmarks/memory_profiler, and you should discuss the issue with the maintainers of those gems. If they think the problem is Sequel-specific and not related to BasicObject subclass instances in general, please ask them to be specific as to the cause. Thanks, Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/d/optout.
