Atomの重要なプリミティブの最適化 | POSTD
これまで数カ月にわたり、私たちはAtomのパフォーマンスの改善に取り組んできました。その結果、最適化するための課題として特に興味深いのが マーカ という構造体だと分かりました。マーカはバッファの内容が変更されても、バッファの論理的な領域を追跡することができます。例えば、以下の図で緑色のハイライトがかかった部分のマーカは、文字列を書き換えたとしても同じ領域に残り続けます。 マーカは、Atomの機能を幅広くサポートする基本的なプリミティブです。検索および置換を行う場合には、マーカを使うことで 検索結果のハイライト表示 ができます。スニペットの場合も、文字列を書き換える際にマーカを使い、 タブストップで移動する位置 を追跡することができます。さらにはスペルチェックの場合でも、マーカを使って スペルミスのある単語を抽出 したり、その単語を書き換える際の再チェックをしたりすることもできます。そもそも
dockerはOS上のディスク領域をどう使っているのかまとめた - Qiita
dockerのディスクの使用方法 dataとmetadata dockerはディスクの管理方法として、dm-thinというDeviceMapperの機能を使います。 詳細は以下を参考にして下さい。 dm-thinの概要 Docker専用のLinux - RHEL Atomic Hostが登場！ dm-thinではデータ領域とメタデータ領域が必要なため、dockerは/var/lib/docker/devicemapper/devicemapperにdataというデバイスファイルイメージと、metadataというデータを作成します。 fileコマンドで確認するとdataはext4 filesystemです [root@master mnt]# ls -lh /var/lib/docker/devicemapper/devicemapper 合計 8.5G -rw-------. 1 root
HTTP/2時代のバックエンド通信検討メモ - ぼちぼち日記
1. はじめに、 今朝、こんな返事を元に kazuho さんとIPsec/TLS等バックエンド通信について議論する機会を得ました。 せっかくだから現時点での自分の考えを整理してメモとして残しておきます。 普段ちゃんとしたストーリをもったエントリーしか書いていないのですが、今回は時間がないのでちゃんとした論理的文章になっていないメモ程度のものです、あしからず。 以下、フロント側に HTTP/2 を導入した場合のバックエンド通信をどう考えるかのメモです。 2. 性能的観点 フロントにHTTP/2を導入したということは、ブラウザのHTTP HoLブロック解消が目的の一つだと思う。HTTP/2の多重化通信によってクライアントからこれまで以上の同時リクエストをさばかないといけない（だいたい初期値は同時100接続ぐらいに制限されていると思う）。 他方バックエンド側通信は、クライアント側がブラウザではな
「通信の最適化」の論点 - めもおきば
論点書き出してみたけど多すぎて超絶カオス。 現状発生している実害 チェックサム比較の失敗(発端) 画質の劣化 exif等メタデータ削除による情報欠損 元ファイルよりサイズが増える 技術的詳細が非公開 「最適化」という単語の是非 オプトインとオプトアウト 送信者(コンテンツ提供者)の同意 自衛のために全HTTPS化することで、かえってトラフィック増える問題 HTTPS化による計算機コスト、ファイル改竄による不具合対応のリスクの負担 サービス内容の意図しない/再現が難しい劣化*1 受信者の財産権の侵害とも言える。 受信者(顧客)の同意 消費者保護観点からより深い内容周知の上での同意が必要では無いか オプトアウトが可能かどうか ISPとしてのサービスが土管であるべきか否か 例えば、可逆圧縮での再圧縮なら良かったのかどうか 携帯キャリアが提供しているのは「インターネット」サービスかどうか iモード
Etsukata blog: FreakOut DSP 入札サーバの CPU 使用率を 30% 削減する Performance Tuning
はじめに 勤務先の FreakOut 社では RTB で広告枠を買い付ける DSP の開発・運用を行っています。RTB とは、インターネット広告のインプレッションが生じる毎に、広告枠の競争入札を行う仕組みです。 DSP とは、 RTB において、競争入札をする側のシステムになります。広告枠/広告を見ている人 に対し、最適な広告を、最適なタイミングで届ける機能を広告主に提供する仕組みです。 FreakOut DSP は最適な広告探索・入札価格調整のため、非常に多くのデータを参照し、沢山の演算処理を行います。広告を見ている人が過去にアクセスした Web ページの情報や検索ワード、さらに 広告がクリックされる予測確率(過去のログから機械学習で算出) などを参照し、入札価格を決定するのです。そのため、DSP で入札を担当するサーバは CPU がボトルネックになっており、台数も数百台に嵩んでいます。
shi3zさんの通信上の圧縮アルゴリズム利用の認識と、big_brosさんによる指摘及び圧縮アルゴリズムの解説 - Togetterまとめ
吉良理人@ねもい @big_bros ゲーム畑出身のフリーランスSE/プログラマ、VOCALOIDで遊ぶDTMerのにわかギター弾き。秋葉原酔狂楽団(仮)楽長。日本飯盒協会員。投稿動画bit.ly/ePqOuE ピアプロpiapro.jp/bigbros まとめ kadongo38氏「日本の通信事業者よりAppleやFacebook, Google の方が問題」 「通信の最適化」でモバイル通信事業者が音声や画像をトランスコード（再圧縮）などする件が話題となっています。 これついて、kawango38氏による高木浩光氏への批判と、同調する意見への批判、及び、それへの反応。 主に、通信の秘密への侵害を問題視する意見への反論。 有益な情報や喧嘩腰な発言など雑多に集めたものです。 kadongo38氏によるshi3z氏のフォローと、それに続くtakagiichiroとの会話 http://toge
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
shi3z on Twitter: "権力って怖いな。ただそれを持つだけで、まるで技術が何も解ってないようなレッテルを貼られる。川上さんはビットレベルで通信プロトコルをコーディングしてそれを仕事にして成功したわけで。ただ人の実装に難癖を付けて税金もらてる高木先生とその取り巻きのコゾー共に実装の話でケチつけられるとは"