タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

pythonとperformanceとnumpyに関するishideoのブックマーク (2)

  • Pythonで省メモリに大量の文字列を扱う工夫 - MNTSQ Techブログ

    たくさんの文字列(や離散的な符号列)をメモリに載せないといけないんだけど、いろんな制約があって通常のList[str]では載らない…ということありませんか?(まぁあんまりなさそうですね) たまたまそういうことがあったので、その際に検討した内容をまとめておきます TL;DR メモリをもっと増やしましょう 富豪的に解決できるならいつでもそれが最高です しかし、世の中それでなんとかならんこともたくさんあります 用途があうのであれば専用のデータ構造を採用する 例えばもし共通のprefixやsuffixが存在し、順序に興味がなければtrie treeなどが使えます 例えば、弊社であれば、法人名をメモリに持ちたいなんてときもあります。そういうときに法人名の辞書をtrieで持ったりすることがあります 「株式会社」「一般財団法人」や「銀行」といった共通語がたくさんでてくるのでtrie treeでごりごり削

    Pythonで省メモリに大量の文字列を扱う工夫 - MNTSQ Techブログ
  • Pythonのfor文は遅い? - atsuoishimoto's diary

    bicycle1885.hatenablog.com こちらの記事を拝見していて、ちょっと気になったので注釈。 PythonやRを使っている人で、ある程度重い計算をする人達には半ば常識になっていることとして、いわゆる「for文を使ってはいけない。ベクトル化*1しろ。」という助言があります。 これは、PythonやRのようなインタープリター方式の処理系をもつ言語では、極めてfor文が遅いため、C言語やFortranで実装されたベクトル化計算を使うほうが速いという意味です。 昔からよくこういう言い方がよくされるが、当にPythonのfor文は遅いのだろうか。 聞くところによるとRのfor文はガチで遅いそうだが、Pythonの計算が遅いのはインタープリタ方式だからでも、for文が遅いからでもない。もちろん、Pythonはインタープリタなので遅いし、for文だって極めて遅い。しかし、これはPyt

    Pythonのfor文は遅い? - atsuoishimoto's diary
  • 1