[#45311] 開発会議 — SASADA Koichi <ko1@...>
笹田です.
10 messages
2012/03/06
[#45312] Re: 開発会議
— "ayumu.aizawa@..." <ayumu.aizawa@...>
2012/03/06
US=1B$B$K$$$k$N$G!"=1B(BSkype=1B$B$H$+=1B(BFaceTime=1B$B$G;22C$7$?$$$G$9!#=1B=
[#45341] 非同期割り込みに対する対処案(日本語版) — SASADA Koichi <ko1@...>
ささだです.
28 messages
2012/03/11
[#45816] Re: 非同期割り込みに対する対処案(日本語版)
— SASADA Koichi <ko1@...>
2012/06/25
ささだです.
[#45817] Re: 非同期割り込みに対する対処案(日本語版)
— Tanaka Akira <akr@...>
2012/06/25
2012年6月25日 18:26 SASADA Koichi <[email protected]>:
[#45819] Re: 非同期割り込みに対する対処案(日本語版)
— SASADA Koichi <ko1@...>
2012/06/25
ささだです.
[#45820] Re: 非同期割り込みに対する対処案(日本語版)
— Tanaka Akira <akr@...>
2012/06/25
2012年6月25日 19:39 SASADA Koichi <[email protected]>:
[#45827] Re: 非同期割り込みに対する対処案(日本語版)
— SASADA Koichi <ko1@...>
2012/06/25
(2012/06/25 20:32), Tanaka Akira wrote:
[#45835] Re: 非同期割り込みに対する対処案(日本語版)
— KOSAKI Motohiro <kosaki.motohiro@...>
2012/06/25
> の3つになるような気がしていますので,ある例外がこれら 3 つのどの状態に
[#45841] Re: 非同期割り込みに対する対処案(日本語版)
— Tanaka Akira <akr@...>
2012/06/25
2012年6月26日 3:40 SASADA Koichi <[email protected]>:
[#45844] Re: 非同期割り込みに対する対処案(日本語版)
— SASADA Koichi <ko1@...>
2012/06/25
(2012/06/26 5:07), Tanaka Akira wrote:
[#45871] Re: 非同期割り込みに対する対処案(日本語版)
— Tanaka Akira <akr@...>
2012/06/29
2012年6月26日 5:15 SASADA Koichi <[email protected]>:
[#45372] Marshal.dumpにおけるインスタンス変数の取り扱いについて — keiju@... (Keiju ISHITSUKA)
けいじゅ@いしつかです.
14 messages
2012/03/16
[#45376] Re: Marshal.dumpにおけるインスタンス変数の取り扱いについて
— Yukihiro Matsumoto <matz@...>
2012/03/17
まつもと ゆきひろです
[#45377] Re: Marshal.dumpにおけるインスタンス変数の取り扱いについて
— keiju@... (石塚圭樹)
2012/03/17
けいじゅ@いしつかです.
[#45381] Re: Marshal.dumpにおけるインスタンス変数の取り扱いについて
— Yukihiro Matsumoto <matz@...>
2012/03/17
まつもと ゆきひろです
[#45399] Re: Marshal.dumpにおけるインスタンス変数の取り扱いについて
— keiju@... (石塚圭樹)
2012/03/18
けいじゅ@いしつかです.
[#45401] Re: Marshal.dumpにおけるインスタンス変数の取り扱いについて
— Tanaka Akira <akr@...>
2012/03/19
2012年3月19日5:54 石塚圭樹 <[email protected]>:
[#45405] Re: Marshal.dumpにおけるインスタンス変数の取り扱いについて
— keiju@... (石塚圭樹)
2012/03/19
けいじゅ@いしつかです.
[#45451] [ruby-trunk - Feature #6218][Open] struct.cのrb_struct_s_members_m()について — "Glass_saga (Masaki Matsushita)" <glass.saga@...>
6 messages
2012/03/28
[ruby-dev:45391] [ruby-trunk - Feature #6129] String#each_lineにおけるmemmem()の利用
From:
Glass_saga <glass.saga@...>
Date:
2012-03-18 08:23:03 UTC
List:
ruby-dev #45391
Issue #6129 has been updated by Glass_saga.
File patch2.diff added
Nobuyoshi Nakada wrote:
>* パラグラフモードでも効果があるか
>* マルチバイト文字の途中にマッチした場合はどうなるか
>また、追加されたコードが既存のコードとかなり重複しているように見えます。 重複を減らすのは難しいでしょうか。
パラグラフモードでも効果があるかどうかについてですが、次のようなベンチマークを実行してみました。
require 'benchmark'
rs = "\n" * ARGV.first.to_i
str = "hoge#{rs}fuga" * 10_0000
Benchmark.bm do |x|
x.report do
str.each_line("") {|s| s }
end
end
"\n" * 2 の場合
proposal:
user system total real
0.070000 0.000000 0.070000 ( 0.070409)
trunk:
user system total real
0.090000 0.000000 0.090000 ( 0.094886)
"\n" * 100 の場合
proposal:
user system total real
0.310000 0.000000 0.310000 ( 0.307020)
trunk:
user system total real
0.320000 0.000000 0.320000 ( 0.320367)
以上のように、連続する改行文字の個数が少ない場合はパラグラフモードでも効果があります。
個数が多くなるにつれてtrunkと同程度の速さになりますが、逆転する事はありませんでした。
>* マルチバイト文字の途中にマッチした場合はどうなるか
お察しの通り正しく動きませんでした。
"表示".encode("SJIS").each_line("\\").to_a.map{|s| s.encode("UTF-8") } #=> ["表", "示"]
(UTF-8環境です)
>また、追加されたコードが既存のコードとかなり重複しているように見えます。 重複を減らすのは難しいでしょうか。
line = rb_str_new5(str, s, sublen)からの4行については関数に切り出す事もできますが、
それ以外の部分については重複を減らすのは難しいと思います。
以下の2点を改善した新しいpatchを添付します。
* rb_enc_left_char_head()を用いて文字境界をチェックするようにした
* configureでmemmem()の第3引数needleが空の場合に発生するバグをチェックできていなかったので修正
* line_yield()という関数を作りコードの重複を削減
----------------------------------------
Feature #6129: String#each_lineにおけるmemmem()の利用
https://bugs.ruby-lang.org/issues/6129#change-24727
Author: Glass_saga
Status: Open
Priority: Normal
Assignee:
Category: core
Target version: 2.0.0
memmem()というGNU拡張のライブラリ関数がありますが、string.cのrb_str_each_line()で可能であればこのmemmem()を利用する事を提案します。
次のベンチマークを実行しました。
require 'benchmark'
str = "hogehifuga" * 100_0000
Benchmark.bm do |x|
x.report do
str.each_line("hi") {}
end
end
結果:
trunk(r34969):
user system total real
0.790000 0.000000 0.790000 ( 0.795141)
user system total real
0.790000 0.000000 0.790000 ( 0.795141)
user system total real
0.790000 0.000000 0.790000 ( 0.795141)
proposal:
user system total real
0.510000 0.000000 0.510000 ( 0.507389)
user system total real
0.530000 0.000000 0.530000 ( 0.541944)
user system total real
0.520000 0.000000 0.520000 ( 0.522825)
以上のように、memmem()を利用する事でパフォーマンスの改善が見られます。
但し、改行文字がrb_default_rsと同一である場合には既にmemchr()を用いた高速な検索が行われるようになっている為、
パフォーマンスが改善されるのはrb_default_rs以外の改行文字を指定した場合のみです。
patchを添付します。
--
http://bugs.ruby-lang.org/