[yast-devel] optimization opportunities in the ycp -> ruby conversion
hello, two topics re y2r (i know i'm horribly late to the party). 1. procedural vs. object-oriented ruby the generated ruby code consists, to a large degree, of function calls emulating semantics of basic ycp operations: Builtins.foreach, Ops.add, etc. these functions are @deprecated, meaning we should go and replace them with native ruby equivalents after checking that the conversion is safe. the point of these emulations is that ycp's nil is a NullObject, you can iterate it like an empty hash or list, you can add it to a number (you'll get nil back), you can concat it with a string or list (same), whereas in ruby you need to if/else around it as stuff like nil.each generates NoMethodError exceptions. but, after perusing ops.rb, builtins.rb, and a few .rb files in yast-installation/, it seems to me that we could have a much more natural-looking ruby code if, instead of having Ops.add all over the place we went for Yast::String#+, Yast::Array#+, etc. it seems there's not so many places where we "return nil", and we could "return Yast::String.new", "return Yast::Array.new" etc in such places. 2. optimization/simplification opportunities in y2r this might not be a representative example, i haven't seen it all. i looked through yast-installation/src/clients/desktop_finish.rb for opportunities to remove some Builtin.foreach calls. it took me about 30 minutes (first encounter with builtins.rb, ops.rb etc) to realize that there's *no reason* for @desktop_order to be pulled through Builtins.foreach: it's always an array. the next thing on my mind was: if *i* can see this, why not the transpiler? the questions here are: is it too late now? if yes, is ther a tool that would let us transform the ruby code? (pls no sed(1) jokes ;) i can see how adding such optimization phases to y2r could require slight changes (hints) to the ycp code, and i don't expect it to do inter-module analysis (though that would enable most gains). i'm afraid that we're going to get stuck with most of the generated code for the next 10 years. there's ~9k lines with Ops.add alone across the generated code, total number of uses of these @deprecated methods will be quite a bit higher, and if we're going to do the analysis (as opposed to a computer), it'll take a very long time, and we're bound to introduce more bugs than the computer would. https://github.com/roman-neuhauser/yast-installation/compare/master...builti... - @desktop_order is initialized with the array literal, so we know the type - it has no getter/setter, so no problems from those - it is reassigned by Builtins operations called on itself; they are guaranteed to return Array if they received one -- roman -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
# rneuhauser@suse.cz / 2013-08-09 14:18:49 +0200:
1. procedural vs. object-oriented ruby
[...]
but, after perusing ops.rb, builtins.rb, and a few .rb files in yast-installation/, it seems to me that we could have a much more natural-looking ruby code if, instead of having Ops.add all over the place we went for Yast::String#+, Yast::Array#+, etc. it seems there's not so many places where we "return nil", and we could "return Yast::String.new", "return Yast::Array.new" etc in such places.
the point is: going from such Yast::String to String would be way cheaper in terms of code churn than going from String|NilClass with Builtins|Ops to String. OTOH, code that looks just like it was normal Array but which treats nils differently could be confusing, so maybe the other bullet (optimize Builtins and Ops away where possible) is more attractive? -- roman -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
1. procedural vs. object-oriented ruby
[...]
but, after perusing ops.rb, builtins.rb, and a few .rb files in yast-installation/, it seems to me that we could have a much more natural-looking ruby code if, instead of having Ops.add all over the place we went for Yast::String#+, Yast::Array#+, etc. it seems there's not so many places where we "return nil", and we could "return Yast::String.new", "return Yast::Array.new" etc in such places.
This was considered and rejected. Going this way would mean that either new code would also need to use Yast::String, Yast::Array, etc., or would have two parallel systems in one codebase. I found both highly undesirable -- much more than Ops.*, etc. Going with native classes is more future-oriented and simpler.
2. optimization/simplification opportunities in y2r
this might not be a representative example, i haven't seen it all. i looked through yast-installation/src/clients/desktop_finish.rb for opportunities to remove some Builtin.foreach calls. it took me about 30 minutes (first encounter with builtins.rb, ops.rb etc) to realize that there's *no reason* for @desktop_order to be pulled through Builtins.foreach: it's always an array. the next thing on my mind was: if *i* can see this, why not the transpiler?
We were operating under the constrain that we need to ship in openSUSE 13.1 (to be included into SLE12). No sophisticated static analysis leading to the optimizations you describe was possible in that time frame with our resources.
the questions here are: is it too late now? if yes, is ther a tool that would let us transform the ruby code? (pls no sed(1) jokes ;) i can see how adding such optimization phases to y2r could require slight changes (hints) to the ycp code, and i don't expect it to do inter-module analysis (though that would enable most gains).
I think we should forget YCP now and do any optimizations purely on Ruby code. That said, I don't know about any tools that could help us with that significantly.
i'm afraid that we're going to get stuck with most of the generated code for the next 10 years. there's ~9k lines with Ops.add alone across the generated code, total number of uses of these @deprecated methods will be quite a bit higher, and if we're going to do the analysis (as opposed to a computer), it'll take a very long time, and we're bound to introduce more bugs than the computer would.
I agree and I would be against mass changes without help of some tools. In reality, I think most code will stay in the current form because it is not touched too much. For active code, I suppose it will be converted into more Ruby-like style gradually as people will work on it. -- David Majda SUSE Studio developer http://susestudio.com/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (2)
-
David Majda -
Roman Neuhauser