[Lv-devel-users] lv 4.51 released

[NARITA T. <nr...@ff...>]

成田多良です.

lv 4.51 をリリースしました.

>> その他、AIX で build できない問題、Mac OS X で build できない問題を
>> メールにして指摘されていまして、合わせて修正し、lv ver.4.51 として
>> リリースしたいと思います。
>> 
>> プレビュー版として lv ver.4.51β2 を作成しましたので、
>> ちょっと確認して頂けますでしょうか。
>> 
>> http://www.ff.iij4u.or.jp/~nrt/freeware/lv451beta2.tar.gz
>> 
>> です。これで OK ならば来週中にはリリースしたいと思います。
>> 他にも何か気になったことがあればご指摘ください。

gotom> どうもありがとうございます。パッチの内容、動作とも確認したところ問題な
gotom> さそうです。

以下の lv の reload が遅い件は、次版以降の課題としたいと思います。


In article <81y...@om...>, GOTO Masanori <go...@de...> writes:

>> と答えてしまいましたが、普通は開かないような巨大ファイルだったりすると
>> G する度に必ずしも意図しない reload が発生して重くなってしまうため、
>> やっぱり、G で自動的に reload するのはやめたいと思います。
>> 
>> その代わり、4.50 で入れた F コマンド (ファイルの polling 機能) で
>> 自動的に reload しますので、それを積極的に使って欲しいと思います。
>> この F コマンドですが、中断が ^C のため上記の「reload 中に ^C で
>> segmentation fault」問題に引っかかって落ちることがしばしばありました。
>> これも後藤さんのパッチで直っています。

gotom> おっしゃるとおり、現状では重くなってしまうため、自動 reload をあきらめ
gotom> るのはしかたないと思います。
gotom> しかし、私としては、最終的には G が重いという点を直すべきだと考えてお
gotom> ります。"F" はあくまでも poll するだけですので、G キーの機能が不足して
gotom> いる点に変わりはないためです。

gotom> 特に、巨大なファイルでこの reload が重くなる点は特に問題視しております。
gotom> 私は、メールをすべて imap で管理しているのですが、一つ一つのファイルの
gotom> サイズが数百MBになることはザラでして、そういったファイルをメーラを使わ
gotom> ずすぐ読むのに lv だととても遅いため、現状では less や tail を（苦々し
gotom> く思いながら :-）使っております。

gotom> 重くなる原因をプロファイルをとって調べたところ、ライブラリ関数 getc() 
gotom> を1バイトずつ呼び出して読むことにほとんどの時間をとられています。そこ
gotom> で、

gotom> 	・複数バイトを一括して読み出す
gotom> 	・ファイルの場合だけは先頭から読まずに途中へ seek してそこから
gotom> 	  読む

gotom> などで高速化できるのではないのかと考えています。ただし、文字コード判定
gotom> を考えないといけないのと、キャッシュまわりに手が入ることになりますが、
gotom> その挙動が完全に理解できていないので、まだパッチを作成するところまで至っ
gotom> ていません。今はどういった方法が一番良いのか考えている最中です。

gotom> 以上から、ファイルサイズが大きくても軽く動作するようになってから、再び
gotom> G を押すと自動 reload するように変更するよう考えたいと思います。

gotom> 成田さんは、いかがお考えでしょうか?

ぼくとしては、大きいファイルの reload が遅いのは仕方のないことだ、
くらいにしか認識していませんでした。

ちょっと色々チャレンジしてみたいと思います。

# 速度に関して気にしたことはあって、昔、超巨大ログファイルでの
# 文字列のサーチなどで less と速度比較をして、目立って差がないことを
# 確認したりしていました。
---
NARITA Tomio, nr...@ff...