You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
はてなダイアリーやニコニコ大百科では、本文のキーワードに自動的にリンクが付くようになっていますが、ニコニコ大百科では、sennaとrubyを使って実装しているそうです。 はてなのようなキーワードリンクをRubyで付与する実例 僕もキーワードリンクを実装する機会があったのですが、そのときはtx-rubyを使いました。 tx-ruby これはtrieというデータ構造を扱うtxというライブラリを、rubyから使うものです。 rubyを介しても十分高速で、以前Wikipediaの見出し語約90万語をキーワードに使って試した際も、非常に高速に動作しました。 大変便利だったので、書いておきます。 tx-rubyのダウンロードはこちらから。 ダウンロードしたファイルを解凍したあと、そのディレクトリに移動して、 ruby setup.rb とすると、簡単にインストールできます。(Windowsでも使えます
技術部のフルタイムRubyコミッタの遠藤(@mametter)です。昨日の Hackarade #04 の開催報告に続き、2日連続で記事を投稿します。 今回は、ある条件下でのRubyの実行速度を高速化した話を紹介します。この改善はすでにMRIの先端にコミットされていて*1、年末リリース予定のRuby 2.6に含まれる予定です。 ひとことで言うと、「簡潔ビットベクトルを索引に使うことで、プログラムカウンタから行番号を計算するアルゴリズムをO(log N)からO(1)に改善した。これにより、TracePoint有効時やコードカバレッジ測定下で、長さ N のメソッドの実行が O(N log N) から O(N) に高速化される」ということです。順に説明します。 背景:Rubyのバイトコードの構造 この最適化を理解するにはまず、Rubyのバイトコードのある特徴を知る必要があります。 たとえば x
Abstract¶ We propose to introduce "2nd" GC managed heap named "Transient heap" into MRI, instead of malloc management heap. Employied GC algorithm is similar to "generational" "copying" GC algorithm. This technique can reduce problems of malloc'ed heap. Background¶ MRI and malloc¶ MRI manages memory by GC managed heap and malloc'ed heap. Objects are allocated from GC managed heap. However, each ob
HashDoS脆弱性との戦い! Rubyコミッター・卜部昌平が明かすプログラム堅牢化のノウハウ 過去、HashDosの影響を受けたRuby。言語開発者はいかにしてこうした問題に対応してきたのでしょうか。コミッターである卜部氏の貴重な記録を公開します。 2011年の末頃、HashDoSという脆弱性が公表され、Rubyもこの影響を受けた。本稿の筆者である卜部昌平(うらべ・しょうへい/@shyouhei/以下、卜部)は、報告当初からRuby側のチームメンバーとしてプログラム本体の修正を担当した。以下はその記録である。言語開発者たちが普段どのようなことを考え、どういった技術を用いて開発やバグフィックスを行っているのか。その概要を知ってもらえれば幸いだ。 オブジェクト指向スクリプト言語 Ruby HashDoSの概要 なぜ約6年後の今、修正内容を公開するに至ったか? 前史:すでに内包されていたリスク
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 数年にわたり、PadrinoやGrapeといったWebアプリケーションフレームワークのルーティングを改善してきた自分が、今年の11月頃から、従来とは異なるアプローチでHTTPルーティングの高速化について検証したので、その結果について解説する。 なおこの記事では、その過程でC++で基数木を実装し、それを用いることにより、Rubyで高速なHTTPルーティングを実現した事例について、順を追って解説する。 tl;dr C++で基数木(Radix Tree)を表現するr2reeというライブラリを書いた。 r2reeのRuby向けバインデ
GitHub - gfx/ruby-regexp_trie: Optimized Regexp builder with Trie (a Ruby port of Perl's Regexp::Trie) # Gemfile gem 'regexp_trie' これははてなキーワードやWikipediaのリンクのように、ある程度の量のテキストに対して大量のキーワードをマッチさせるときに、最適化した正規表現を生成するライブラリです。 はてなキーワード*1をとあるブログエントリ*2にマッチさせるための簡単なベンチマークもあります。 example/benchmark.rb 結果: $ bundle exec example/benchmark.rb (snip) user system total real Regexp raw 4.270000 0.030000 4.300000 ( 4.3
qiita.com mattn.kaoriya.net という記事を読んだのでアルゴリズムを改善して速くしました。 いわゆる行列累乗のテクニックを使うと(乗算部分を除けば)N番目のフィボナッチ数はで求まります。 実際にはフィボナッチ数は指数的に増大するので乗算にかかる時間が支配的になるのでもっと遅くなります(Karatsuba法なら、高速フーリエ変換を使えば)。 単純な足し算のループでは足し算の桁数を考えると なのでそれよりは随分と速くなります。 40番目ぐらいでは実行時間はほとんど0なので100万番目のフィボナッチ数を求めてみます。 こちらが元のソースコード def fib(n) f0, f1, v = 0, 1, 0 n.times do |x| if x <= 1 v = x else v = f0 + f1 f0, f1 = f1, v end end return f0 + f1
Subject: [ruby-dev:49209] データ構造コンテスト:テーブルデータ構造の再考 From: SASADA Koichi <ko1@ d . t Date: Wed, 12 Aug 2015 19:10:54 +0900 # 概要 Ruby インタプリタのデータ構造についての協力者を募集します。具体的には、 特定のテーブルデータ構造の高速化、およびベンチマークの作成です。題目にコ ンテストと書いていますが、とくに賞品はありません。 # 詳細 Ruby インタプリタでは、テーブルデータ構造を使っています。テーブルデータ 構造だと曖昧ですが、Ruby だと Hash クラスに代表される、あるキーに対して 特定の値が返る、というデータ構造と考えてください。キーに重複はないことと します。 Ruby インタプリタのテーブルデータ構造には、st というデータ構造が利用され ており、
by Martin Pool This project has moved to github.com/sourcefrog/natsort. Computer string sorting algorithms generally don't order strings containing numbers in the same way that a human would do. Consider: rfc1.txt rfc2086.txt rfc822.txt It would be more friendly if the program listed the files as rfc1.txt rfc822.txt rfc2086.txt Filenames sort properly if people insert leading zeros, but they don't
かつてのMac OS9までの描画エンジンの主役はQuickDrawが担っていた。GUIなOSでは、文字も含めてすべてをグラフィックとして扱うので、画面に見えているすべてのもの*1はQuickDrawによって描かれていたことになる。描画エンジンは、GUIなOS開発の要となる技術である。その出来が、GUIなOS開発の成否を分けるとも言える。 そして、最初期のQuickDrawは、ビル・アトキンソンがたった一人で開発したそうである。 当時(25年以上前)のCPUは、動作クロックが8MHzという性能だった。(現在は2GHz=2000MHzかつ、複数コアが当たり前) そのような性能であっても、違和感なくマウスで操作できるOS環境にするために、斬新な発想や試行錯誤を重ね、相当な努力の末に開発されたのがLisaやMacintoshであった。 Amazon.co.jp: レボリューション・イン・ザ・バレー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く