前 | 2017年 12月 |
次 | ||||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |
此れが終わってから此の処理を、と云う時のために.
IE対策で Promise は別途入れなきゃ行けないのが気に食わないが、
MutationObserver と組み合わせて実現!
・・・・あぁ、無駄が無い処理は美しい(気持ち的に)
setTimeout も一部使っているが、主にエフェクト待機用.
なので、事前に new Date() で開始時刻を保持しておき、Promise からの MutationObserver で終わってから、再度 new Date() で経過時間を取得し、
元々のエフェクト待機時間から引いた上での setTimeout !!
あぁ、無駄が無い(処理時間的に)
効率の良くない組織だな、と漠然と感じる場合、何が問題なのだろうかと思っていたが・・・・
信頼していない.
だから十分な裁量権を与えない. 逐一報告を求める、指示を出す、のために多様な会議が催される.
そんな息苦しい中で、自分で考えて動けと云われるが、十分な権限は無い中で、と云う条件が付く.
これで「スバラシイパフォーマンス」が発揮されるのであれば、異常者認定させて頂きたい!(爆)
やはり相応の権限(と責任)が無いと、ガッツリ動けるワケが無い.
翻って現状を見ると・・・・アレか・・・・
過去にあった不逞の輩がやらかした「事」が尾を引いてのであろう.
不信とまでは行かなくとも、コントロールしないと不安なのであろうなぁ・・・・結果、そうで無い人も潰すことになるのだけれども.
この辺が「システマチック」にせざるを得ない大企業の方が、効率的になるのであろう.
微妙と云える損耗率で、気付き難い事甚だしい.
「ストレスチェック」が課されるようになって暫く経つが、当初は「で?」と云う感想しか無かった結果表記なのだが・・・・チョットマテ.
マズい状態だよね?! と、客観視すれば不毛な損耗戦に陥っているでは無いか.
微妙過ぎて気付き難いが、これぞゆでガエルが出来上がる理論だな.
我が身で起こると一切笑えない.
・・・・進行度合いや期間に因るだろうが、最後は鬱病か過労死か、碌でもない未来が待っているのは請け合いだ.
さて、幸いなことに無事なうちに現状認識ができなのだから、早々に脱すべく手を打たねば! ・・・・手札は心許ないが.
小・中学生なら「学校に隕石が落ちたらいいのに」ってなヤツだ(笑)
社会人になると「あいつ、(自主規制)んだらいいのに」(ぉぃ
実際に起こる事は無く(だから酷い事でも思う)それでも思ってしまうのは・・・・娯楽としての非日常を求めているであろう.
其れを「娯楽」と断言する事は何事か、と云われそうであるが、FPSで敵をバンバン打ち倒す、ってのと大差は無い.
そんな「攻撃的な内容のゲーム」が原因で「現実世界でも~」なんてのを本当にやらかすのは頭のオカシイヤツだけなので、そんなのは放っておいてもオカシな事をしでかすのだ・・・・・
マリオでクリボーを散々踏んづけているのに、街中を歩いていても踏んづけて踏んづけられてしている人は何処にもいない. 一度も見たことが無い!
そんな光景がそこかしこで見られたら、非日常で楽しそうだなぁ(ぉ
KVM で使う image ファイル、qcow2 ならもちろん、raw でも sparse file なら設定容量では無く使用量分のファイルサイズで済む.
書き込み拡張時のオーバーヘッド?! 実サーバの空き容量に余裕がある時のみ云えるセリフだ!!(爆)
だが、しかし!
仮想サーバが稼働を続けて行くと徐々に肥大化していく・・・・image file・・・・
qemu-img convert でも(多少は)小さくなるが、使用量との乖離が激しい・・・・
で、調べてみたら最新版にはあった・・・・ virt-sparsify が!
/tmp 領域にコピーしながら一時的な仮想サーバ(?)に展開しながら整理している模様.
展開(整理)が終わったら、一時的な仮想サーバは落ちて出来上がったイメージを qemu-img でコンバートして完了.
設定ディスク容量の「空き」が /tmp に要るのでそのままだとダメ~
virt-sparsify --tmp [dir] [base image file name] [new image file name]
で出来た!
速度と処理時間はディスクアクセス速度と image file の「設定容量」に依るなぁ.
100GB設定、image size 15GB、中身は 8GB弱 程度のファイルで 40min ほど掛かったが、image size が 8GB強 ほどになった!
速度がアレだが効果はバツグンだナ!
Arm版「フル」Windows で、愈々開戦だ!
性能ありきで来た、x86. 電力効率重視で様々な省電力機構を組み入れ、10時間駆動なノートPCもちらほらある.
バッテリー駆動が基本の、省電力が主力の Arm. スマートフォンやタブレット端末の高機能化に伴い、コア数やクロック数の向上で「電力効率」も大事にしつつ性能を上げてきた.
出自から向かった先がお互いに逆方向でいよいよ正面衝突・・・・・なのだろうけれども.
Arm版、20時間駆動・・・・・
性能を犠牲にし、現状では 32bit な x86 アプリしか走らない、と云う制限はあるものの、差は激しいようで.
64bit は技術なのか効率なのか、まだ問題はあるようだが「特化」するとさすがに強いなぁ.