2004-04-12
メモリ動的確保
「Cの動的メモリ確保が遅いのかも」ということなので、ちょっと調べてみました。
まず、malloc/freeがどのように実装されているかというと、詳細は説明するのが面倒なので「プログラミング言語C第二版」の記憶割り当てあたりを参照してもらうとして、簡単に言うと二つの機能により実現されています。
- OSからの動的メモリ確保
- リンクによる空きリストの管理
同一の関数の中で可変長配列とallocaの両方を使うと、 可変長配列の領域が解放されるときに、 その可変長配列が割り当てられたあとにallocaによって割り当てられた領域も すべて解放されることになります
[C言語ファミリに対する拡張機能より引用]
というところからの推測です。そして、allocaの実装がどうなっているかというと、多くの場合スタック上にメモリを確保していると思われます。
こうすることにより、関数を抜けたときに領域が開放されるという仕様がより自然に実現できます。
そして、スタックポインタの操作だけですむgccの可変長配列の方がmallocによるメモリの動的確保より速いのは自明でしょう。
2006-04-12
alps.rbのバグ(2)
さらに続き。
結論としては、alps.rbの43行目が問題だと思う。
i = (@mode == 'append') ? (ary.length - 1) : 0
追記した場合に追記部分だけ検索するための処理だと思うのだけど、これだと2セクション以上追記した場合に、最後のセクション以外は検索しないというバグも潜在的にある。これは意図した動作ではないだろう。
追記したセクションのみ取り出すことができるのであれば、それでいいのだけど、編集モードの場合はすべてのセクションを走査しているので、追記モードの場合でも単純にすべてのセクションを走査すればいいのではないだろうか。
+ i = (@mode == 'append') ? (ary.length - 1) : 0 - i = 0
パッチとしてはこんな感じ。whileをary.eachにしてもいいかな。
2007-04-12
2020-04-12
在宅勤務をしている
3月の三連休が明けてから月末にかけて「やっぱりヤバいんじゃね」という空気感でとにかく週末は外出自粛という話にはなっているけど出勤は普通にしている状態で、会社的には在宅勤務という選択肢はありつつもリーダーという立場上自分だけ実施というわけにもいかず*1、という状況だったのだけど、会社の方針としてひとまず4/1から4/10まで出勤する人員を7割にするということでチーム全体で実施できますということで手をあげて4/2から全面的に在宅勤務に移行した*2。
そこから後は、4/6(月)に非常事態宣言検討中、4/7に非常事態宣言するよ、4/8に宣言発出、会社的には4/10にようやく可能な限り在宅勤務という方針が発表された。
1月に部署を異動して開発環境の整備から行ったなかで、ベストな環境(GitHub + プロジェクト管理用のSaaS)には持っていけなかったのだけど、Azure DevOpsで社外からもアクセスできる環境にしていたことで、結果的に思ったよりはスムーズに作業ができる環境にはなっていたのだけど、一週間ちょっとダイニングテーブルで作業を実施した結果椅子だけはちゃんとしたものを使わないと腰がヤバいということで椅子を購入、それに合わせてある程度場所も整えることにした。
巷では在宅の作業環境としてかっこいい写真が上がっていたりするけど、いまのところとしてはまあ頑張ったほうだとは思う。色々写り込んでいるのは気にしてはいけない。ちなみに机の下にはゲーム用の自作PCがおいてあって、休憩時間にはすぐさまゲームを始められるようになっている。