Raspberry Pi の64-bitと32-bitで、パフォーマンスはどのように変わるのか？ (メモ置き場) - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
Rust のパフォーマンスに何が影響を与えているのか - Qiita
動機 The Rust Performance Book という書きものを見つけました。いろいろなパフォーマンス改善テクニックが書かれているわけですが、実際に普段書いてる Rust コードの中で一体何がパフォーマンスに与える影響が大きいのか？という点が気になってベンチマークを取ってみました。 今回パフォーマンスを計測するプログラムはビットマップ画像（1600px x 1200px）をグレースケールに変換する処理です。I/O のパフォーマンスは無視します。&[u8]から RGB をそれぞれ 1byte ずつ（合計 3bytes）取ってきて、それをグレースケールの 1byte に変換してVec<u8>にする時間を計測します。イメージとしては下記のような関数です。 // source が カラーのビットマップ画像のデータ fn sample(source: &[u8]) -> Result<Ve
結局useMemoはいつ使えばいいの？ 僕の決定版 - Qiita
皆さんこんにちは。筆者の以前の記事では、ReactのuseMemoを無駄に使うことによるレンダリング速度のオーバーヘッドがどれくらいかをベンチマークによって示しました。 それによれば、スマートフォンを想定したとしても、useMemoだけで描画に目に見える影響を与える（16msくらいの遅延を発生させる）には万のオーダーのuseMemoが必要なことが分かります。 この結果が出たことでuseMemoをいつ使うのかなどという議論には終止符が打たれたかと思いきや、上記の記事の感想などを見ているとまだ喧々囂々です。 そこで、この記事では筆者の考えを皆さんに共有し、いよいよもってこの議論を終わりにしたいと思います。 結論は、今いる関数の外を見に行くな。そのuseMemoが今または将来に役に立つ可能性が1%でもあるなら使えです。 前提知識 useMemoというのは結局レンダリングパフォーマンスの最適化のた
そこのお前！ 余計なuseMemo1個に含まれるオーバーヘッドは余計なdiv 0.57個分だぜ！ - Qiita
※効果には個人差があります。 useMemoのオーバーヘッドについて ReactのuseMemoは、パフォーマンス最適化に使われるAPIです。コンポーネント内で計算やオブジェクトの生成を行う際に、以前の計算結果をキャッシュして使い回すことで再レンダリング時の計算を削減したり、新しいオブジェクトの生成を防ぐことができます。 useMemoに関しては、あくまで最適化のためのものであるから「無駄に使うべきではない」という言説がよく見られます。その理由は、useMemoのコストもゼロではなく、余計な使用はそれだけパフォーマンスの低下に繋がってしまうからです。 しかし、筆者はuseMemoのコストは微々たるものであり、本当に一目見て明らかに無駄でない限りは積極的に使うべきだと思っています。 そこで、筆者はuseMemoのオーバーヘッドがどれくらいかを調べるためのベンチマークを作成しました。この記事で
Pythonistaなら知っておきたい計算量のはなし - Qiita
最近久しぶりにアルゴリズムイントロダクションを読んでいるのですが、ふと「Python(CPython)のデータ構造に関する各操作の計算量ってどれくらいなのかな？」と気になったので調べてみました。以下のページを参考にしています: Python Time Complexity 以下では $n$ や $k$ といった記号を使います。ここで $n$ はコンテナ内の要素数、$k$ はパラメータ内の要素数かパラメータの値とします。では見ていきましょう。 2021/05/02 コメントでのご指摘を記事に反映しました。ありがとうございます。 リスト まずはリストです。Pythonではリストは内部的にはC言語の配列として表しているようです。そのため、先頭要素の追加や削除を行うとそれ以降の要素をすべて移動する必要があるため大きなコストがかかります。なので先頭に要素を追加したり削除する必要がある場合は、代わりに
ArmにあるというJavaScript専用命令とは何か、あるいは浮動小数点数を整数に変換する方法について - Qiita
元の値の絶対値が大きすぎる場合や、無限大、NaNの場合は、 6.3.1.4: 表現できない場合はundefined behavior。 Annex F.4: 表現できない場合はinvalid例外が発生して、値はunspecified。 とされています。 これ以外の浮動小数点数→整数型の変換方法には (l)lrint や (l)lround 関数などがあります。 Java 基本的に0方向への丸め（切り捨て）で計算されますが、コーナーケースについても言語仕様で定めています。 NaN：0を返す 結果が表現できないもしくは無限大の場合：符号に応じて最大値または最小値が返る。 参照： 5.1.3. Narrowing Primitive Conversion - Chapter 5. Conversions and Contexts JavaScript JavaScriptではビット演算やいくつか
Docker for Mac の Mutagen-based caching で Volume のパフォーマンスが劇的に改善した - Qiita
2020/8/23 追記 2.3.5.0 の Edge release で削除されてしまった模様です。 今後の統合方法を検討するということで、続報を期待します。。 Docker for Mac の Edge channel で、 Mutagen ベースのキャッシュが使えるようになっています。(手元のバージョンは 2.3.1.0) 従来、 EC-CUBE をはじめとする Symfony をベースとしたアプリケーションや、Composer や npm などのパッケージ管理システムのファイルをマウントすると、強烈に遅くなる問題がありました。 今回利用できるようになった Mutagen ベースのキャッシュを利用するには、 Preferences -> Resources -> FILE SHAREING でマウントするディレクトリを指定 キャッシュを ON にするだけ。 です。 あとは通常通り、ア
webpack 5 の webpack federation という概念について - Qiita
注意: まだHEADにすらマージされていない機能です。 僕の現状の理解で書いてます。細かいニュアンスは見落としてるかも。 今の課題 異なるチームで、異なるビルドプロセスのものを統合するような巨大なフロントエンド、いわゆるマイクロなフロントエンドやってると、同じようなライブラリが内部的に重複するよね webpack build (chunk) 間で、そういう自明なもののを重複を省いたり、一方向ではなく、相互に読み出せるようにしたいよね ScriptedAlchemy氏の提案 異なるWebpackビルド同士が連携する、Federation という概念を作る。 Host と Remote という概念を追加する。既存のものは Host となる(?)。 Remote は、それぞれに要求する chunk (react, vue など)と、他に外側に提供するインターフェースを明示する。 (optimaz
CSSを非同期ロードする最も簡単な方法 - Qiita
CSS読み込みの<link rel="stylesheet">は同期なので、レンダリングブロックします。 どういうことかというと、CSSファイルの読み込み・パースが終わるまで画面描写が止まってしまいます。 これに対策する方法としてpreloadというものが策定されましたが、対応状況が微妙です。 2019年7月時点でもブラウザシェアが8割しかなく、Firefoxは当面対応するつもりがないようです。 とはいえ残り2割のためにloadCSSを突っ込んだりとか始めると本末転倒感に溢れます。 全ブラウザ対応のためには、なんにしろ結局JavaScriptをこりこり書くしかない状況でした。 が、なんかすっごい簡単な対処法があったので紹介してみます。 以下はScott Jehlによる記事、The Simplest Way to Load CSS Asynchronouslyの日本語訳です。 ちなみにSco
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
