GitHub - borisdj/EFCore.BulkExtensions: Entity Framework EF Core efcore Bulk Batch Extensions with BulkCopy in .Net for Insert Update Delete Read (CRUD), Truncate and SaveChanges operations on SQL Server, PostgreSQL, MySQL, SQLite
EntityFrameworkCore extensions (performance improvement): -Bulk operations (super fast): Insert, Update, Delete, Read, Upsert, Sync, SaveChanges. -Batch ops: Delete, Update - Deprecated from EF8 since EF7+ has native Execute-Up/Del. -AddOp: Truncate. Library is Lightweight and very Efficient (warp speed), having all mostly used CRUD operation. Was selected in top 20 EF Core Extensions recommended
[Python] SQLAlchemyを頑張って高速化 - Qiita
はじめに pythonからMySQLを叩く際，何を使っていますか？SQLAlchemy,Django,peeweeあたりを使っている方が多いのではないでしょうか．私は色々使ってみて結局SQLAlchemyに落ち着いていますが，何千万，何億オーダのデータになると処理が遅く非常にやっかいです． なので今回は（大きなデータにsql使うなとか高速処理にpython使うなという話は一旦置いておいて），SQLAlchemyを使ったデータ処理をいかに高速にするか，何項目かに分けて備忘録を残しておきます． SQLAlchemyを~と書いてありますが，SQLAlchemyを使ってDBにデータをINSERT,SELECTする際のpython高速化TIPSごった煮です．本当は記事を分けたほうが良いのですが，自分で見返す際にまとまっているほうが嬉しいのでこうしました． なお，今回使用するコードは全てgithubに
![[Python] SQLAlchemyを頑張って高速化 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/6be9cd2919b07c8dc369d70f612aa1e65e31edd6/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCUHl0aG9uJTVEJTIwU1FMQWxjaGVteSVFMyU4MiU5MiVFOSVBMCU5MSVFNSVCQyVCNSVFMyU4MSVBMyVFMyU4MSVBNiVFOSVBQiU5OCVFOSU4MCU5RiVFNSU4QyU5NiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9YmM0MmFhMzk0YTU5MDJiY2M1NTQ4MDczZWE5OWYxMWI%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB5dWtpQiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MmUzODc2ZTk3MWM5YTdjNGFlYWUzNWZjMDZhMzcxYjQ%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-44OG44Oz44Kv44O8%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D2abf4c1ae15fe8db2e7581a9c7858d7d)
フォワードコンピュテーションを並列化！？これまでの固定概念を崩す研究の登場！
3つの要点 ✔️ 深層学習の逐次的な計算であるフォワードコンピュテーションを並列化する手法の提案 ✔️ フォワードコンピュテーションを複数の非線形な方程式と見なし、ソルバーから計算 ✔️ フォワードコンピュテーションを最大33倍高速化することに成功 Nonlinear Equation Solving: A Faster Alternative to Feedforward Computation written by Yang Song, Chenlin Meng, Renjie Liao, Stefano Ermon (Submitted on 10 Feb 2020) Comments: accepted by arXiv Subjects: Machine Learning (cs.LG); Machine Learning (stat.ML) はじめに 深層学習は画像認識をはじめ
たった一文でPandasのapplyメソッドを高速化する方法（検証計算あり） - Qiita
以下では、DaskやPandasなどと比較して、swifterがどの程度高速なのかを検証したいと思います。 swifterはベクトル化可能な場合とそうでない場合で挙動が異なるので、各々の場合を検証します。 使用したPCのスペックはIntel Core i5-8350U @1.70GHz、メモリが16GBです。 ベクトル化可能な場合 swifterはベクトル化可能なときはベクトル化するので、swifterの計算時間は単純にベクトル化した場合と ほぼ等しくなるはずです。これを確認してみましょう。 import pandas as pd import numpy as np import dask.dataframe as dd import swifter import multiprocessing import gc pandas_time_list = [] dask_time_list
ブラウザレンダリング入門〜知ることで見える世界〜 - Qiita
はじめに 『レンダリングの仕組みなんて知らなくても、ブラウザが勝手にやってくれるじゃん！』 当時駆け出しのエンジニアだった私はそう思っていました。 実際、当時の私はレンダリングの『レ』の字も知りませんでしたが、特に業務上で問題はありませんでした。 しかし、その時は突然訪れました。 クライアントの要望でアニメーションを多彩に取り入れた案件を実装した際に、テスト段階で一部ブラウザ（S○f○ri、E○ge）でアニメーションがひどい状況になっていることが発覚しました。 (開発中はChromeで確認を行っており、Chromeでは特に問題はなかったので発覚が遅れました。) それからは、狂ったようにパフォーマンスの改善方法をググり、修正する日々が続きました。（最終的には、なんとかマルチブラウザでの動作も担保し、納品まで完了しました。） その案件が落ち着いた後、改めて自分の調べたことを振り返ると、局所的な
Chainer/ChainerMNのおすすめなプロファイルの取り方＆プロファイルの見方の注意点 - Qiita
自分への備忘録的な意味も込めて最近まとめたので、私が実践しているChainer/ChainerMNのプロファイルの取り方とプロファイル結果の見方を紹介します。 この記事で使うプロファイラは、Chainerのプロファイルを取る際まず取るべきと思われるcProfileとnvprofの二つです。 環境 Python: 3.6 Chainer: 5.2 CuPy: 5.2 CUDA: 9.0 MPI: OpenMPI 1.10.7 参考コード この記事ではChainerMNのmnistのサンプルをベースに改造したコードで説明を行っています。 mnistのオリジナルのコードはこちら。 https://github.com/chainer/chainer/blob/v5/examples/chainermn/mnist/train_mnist.py 改良後のコードはここに上げてあります。 https:
pandasで1000万件のデータの前処理を高速にするTips集 - Qiita
はじめに 当社にアルバイトに来ていた人（来春に新卒入社の予定）に「pandasを高速化するための情報は無いですか？」と尋ねられました。 このパッケージの使い方は多数の書籍やWebで体系立った記事で書かれています。 しかし、高速化に関しては体系的な情報源が思いつかなかったので、「実際に書いてみて、1つ1つチューニングするしかないです」としか答えられませんでした。 そこで、この方を始め、来春（2019年4月）にデータアナリストまたはデータサイエンティストになる新卒へ向けて、pandasの高速化に関する私の経験をTips集にしてお伝えしたいと思います。 この記事は今後も内容を充実させるために、Tipsを追加していきます。 この記事を読んだ後にできるようになること pandasでレコード数1000万件のデータでも1分以内で完了する前処理が書けるようになります。 その結果、1日中実行し続けなければな
お前らのReactは遅い - Qiita
煽りタイトルですみません。 最近、Reactのプロジェクトのページを動かしていて、 もっさりしてる（レンダリングの負荷が高いな）と思ったので どうやったら無駄なレンダリングを減らせるか思考錯誤したことをまとめました。 preactとか別ライブラリの話はしません。 よかったらこちらもどうぞ ReactJSで作る今時のSPA入門（基本編） 2019年07月06日追記： ブラウザのレンダリングの仕組みに関して良記事があったので先に一読しておくことをおすすめします。 良記事１：実際のところ「ブラウザを立ち上げてページが表示されるまで」には何が起きるのか 良記事２：ブラウザレンダリング入門〜知ることで見える世界〜 １ピクセルがブラウザに表示されるまで：Life of a Pixel 2018 この記事に関してはReactのDOMツリー（レイアウト）レンダリングに関する最適化戦略です。 2020年02
光を超えるためのフロントエンドアーキテクチャ - Speaker Deck
HTML5 Conference 11/25
Customer Notes: Diagnosing issues under load of Web API app migrated to ASP.NET Core on Linux - Scott Hanselman
When the engineers on the ASP.NET/.NET Core team talk to real customers about actual production problems they have, interesting stuff comes up. I've tried to capture a real customer interaction here without giving away their name or details. The team recently had the opportunity to help a large customer of .NET investigate performance issues they’ve been having with a newly-ported ASP.NET Core 2.1
dev.toに匹敵する速度を出せるWordPressテーマを開発した話 - Qiita
本日、無料WordPressテーマ Godios. をリリースしました。 公式サイトを見ていただけるとわかると思うのですがページが一瞬で遷移しています。 どうでしょう、dev.toと同じくらい速いんじゃないでしょうか。 この記事ではテーマを高速化するにあたって用いたテクニックを書いていきたいと思います。 圧縮 テーマに含まれている画像・CSS・JSファイルの圧縮。 画像はOptimizilla・TinyPNG、CSSはCSS Minifier、JSはJSCompressを使用しました。 CSS・JSファイルの遅延読み込み レンダリングをブロックするファイルが大量にあると表示が遅くなりますので、JSファイルはdeferまたはasync属性を付与し、CSSファイルはインライン、またはJSで非同期に読み込んでいます。 無駄なSQLクエリを減らす データベースへのアクセスが多いと負荷が掛かる上、速
いもす法 - いもす研 (imos laboratory)
いもす法とは，累積和のアルゴリズムを多次元，多次数に拡張したものです．競技プログラミングでは 2 次元 1 次のものまでしか出題されませんが，2012 年の研究成果としてこれをより高次元の空間により高次数のいもす法を適用することにより信号処理分野・画像処理分野において利便性があることがわかっています． いもす法の基本: 1 次元 0 次いもす法 最もシンプルな「いもす法」は 1 次元上に 0 次関数（矩形関数や階段関数などのように上部が平らな関数）を足すものです． 問題例 あなたは喫茶店を経営しています．あなたの喫茶店を訪れたそれぞれのお客さん i\ (0 \leq i \lt C) について入店時刻 S_i と出店時刻 E_i が与えられます（0 \leq S_i \lt E_i \leq T）．同時刻にお店にいた客の数の最大値 M はいくつでしょうか．ただし，同時刻に出店と入店がある場
Efficient R programming
Efficient R programming Colin Gillespie Robin Lovelace 2021-03-18 Welcome to Efficient R Programming This is the online version of the O’Reilly book: Efficient R programming. Pull requests and general comments are welcome. Get a hard copy from: Amazon (UK), Amazon (USA), O’Reilly Authors Colin Gillespie is Senior Lecturer (Associate Professor) at Newcastle University, UK. He is an Executive Editor
プログラムを高速化する話
KMCの例会講座で用いたスライドを一部編集したものです。 ビット演算を組み合わせたトリッキーな方法で様々な操作を高速に行う方法を紹介します。
私が書いた最速のハッシュテーブル – PART 2 | POSTD
素数か2のべき乗か ハッシュテーブルのアイテムをルックアップする際に高負荷なステップが3つあります。 キーをハッシングする キーをスロットにマッピングする 該当スロットのメモリをフェッチする ステップ1は、キーが整数であれば、低負荷になります。単にintをsize_tにキャストするだけです。しかし、文字列のようなタイプのキーの場合は高負荷となります。 ステップ2はよくある整数モジュロ演算です。 ステップ3はポインタの間接参照です。std::unordered_mapの場合は複数のポインタ間接参照となります。 処理の遅いハッシュ関数でなければ、直観的にステップ3が最も高負荷になると考えると思います。しかし、全てのルックアップでキャッシュミスが生じなければ、整数モジュロが最も高負荷な処理となります。現代のハードウェアにおいても整数モジュロは非常に遅いのです。 Intelマニュアル では、整数モ
私が書いた最速のハッシュテーブル – PART 1 | POSTD
結局、やり出したら止まりません。私は以前、” I Wrote a Fast Hashtable（私が書いた高速なハッシュテーブル） “という記事と、それに次いで” I Wrote a Faster Hashtable（私が書いたより高速なハッシュテーブル） “という記事をブログにアップしましたが、今回ついに、最速のハッシュテーブルを書き上げました。これが意味するところは、ルックアップがどのハッシュテーブルよりも速いということです。それに加えて、挿入や削除も（最速とまではいかないまでも）非常に速く行えます。 秘訣は、探索回数の上限を設定したロビンフッドハッシュ法を使用することです。ある要素が、その理想的な位置からX数以上、離れた位置にある場合、テーブルを拡張することで、全ての要素が、その大きなテーブル内において、理想的な位置に近づくようにします。結果的に、このやり方は非常にうまくいきました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Deep Learning推論を高速化するソフトウェア技術
How to parse a high rate stream of data with low memory allocation – The Functional Programmer
モデルアーキテクチャ観点からのDeep Neural Network高速化
3次元計測とフィルタリング
