Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

inefficient data fetching due to uncached time extraction

オープン
#115 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
python
領域
data, performance

調査の方向性

src/wrf/util.py の 1609 行目から始め、周辺の短絡パスとキャッシュ機構を追跡し、渡された _key が他の場所でどのように使われているかも確認します。多くの WRF ファイルにおける現在のデータ取得動作を比較し、結果を必要としないパスを変更せずに、キャッシュされていないと疑われる時刻抽出を確認して対処することを done と定義します。

索引モデルが issue の本文から書いたものです。

説明

support

https://github.com/NCAR/wrf-python/blob/bd1107c605f7f51c712d3a1d22cf359bfcbad874/src/wrf/util.py#L1609

https://twitter.com/JaredALee/status/1263311504469889031

A friend using this package to extract data across many wrf files was encountering huge slowdowns and found huge speedups switching to xarray. I dug a bit and I have a suspicion where the inefficiency is. There are two things about the linked line that concerns me. First, It is called before a possible short-circuit path that doesn't use its result, so perhaps this line can get moved to a few lines down? Second, I notice that this function call doesn't use the passed in _key. I don't fully understand the cache mechanism, but I wonder if this would benefit from it?

主要言語
Python
スター
498
フォーク
178
PR マージ指標
30日以内にマージされた PR はありません

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

NCAR/wrf-python のほかの issue

NCAR/wrf-python の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。