Hi.
Well, as you can see, this part has nothing to do with Syck either. It is
not the speed of YAML-parsing that's the issue (at least not yet... =), but
the speed of this particular
code fragment. And yes, I had the patience to let it work in about 25k
lines before it started to make my other work on the computer hard. it's
not looping forever, as far as I can see.
Tonight I'm going to get it going before heading for bed, and see what
happens if the routine reduce_spec actually finishes.
So, to recap, the method reduce_spec is in remote_installer.rb in RubyGems,
and it's not a YAML-issue yet. Probably it's a combination of many regexps
and substitutions that's doing it slow.
Regards
Ola Bini
At 16:09 2006-04-07, you wrote:
I was going to ask if it was working on a zlib thing, but I can see it
is already inflated. Something tells me this could have been the motivation
for moving to Syck.
Have you put in prints or the like to make sure this thing is
not just looping over the same stuff endlessly? I am hoping we
are doing something stupid that we can fix versus being so glcially
slow we cannot iterate over a 350K yaml file.
If we really are that slow we should hack that newer java-based
yaml parser into our code (make it pluggable). The name is escaping me.
-Tom
On Fri, 07 Apr 2006, Ola Bini defenestrated me:
> Hi.
>
> The stopgap for RubyGems now seems to be this method, where it has spent
> more cycles and hours than I care to count:
> def reduce_spec(yaml_spec)
> result = ""
> state = :copy
> x=0
> yaml_spec.each do |line|
> if state == :copy && line =~ /^\s+files:\s*$/
> state = :skip
> result << line.sub(/$/, " []")
> elsif state == :skip
> if line !~ /^\s+-/
> state = :copy
> end
> end
> result << line if state == :copy
> end
> result
> end
>
>
>
> I can't really say that it hangs there, it seems to continue. But the
> yaml_spec is a string about 3500000bytes long, and I haven't even seen it
> reach end.
> Is there some obvious point in this code where the JRuby internals
could be
> optimized to make these operations usable?
>
> Regards
> Ola Bini
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Jruby-devel mailing list
> Jruby-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jruby-devel
--
+ http://www.tc.umn.edu/~enebo +---- mailto:[EMAIL PROTECTED] ----+
| Thomas E Enebo, Protagonist | "Luck favors the prepared |
| | mind." -Louis Pasteur |
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jruby-devel mailing list
Jruby-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jruby-devel
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jruby-devel mailing list
Jruby-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jruby-devel
