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

Improve performance by removing SHA

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

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
python
領域
performance

調査の方向性

markdown2.py で _hash_html_block_sub と _hash_text を読み始め、それらが生成するキーが変換中にコンテンツを保護および復元する仕組みを追跡します。現在のハッシュ処理のコストをプロファイリングし、そのうえで、どのような置き換えでも変換の動作が維持され、キーの衝突が回避され、パフォーマンスが向上することを検証します。

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

説明

The performance could be faster.

When I profile my blog build, about 60% of the time spent in markdown2.py is spent running SHA hashes.

Could you explain the logic of _hash_html_block_sub and _hash_text generally? Why are we even running SHA inside a markdown converter?

It looks like... this is some some of escape mechanism, maybe? Like we generate a key, replace the HTML with the key (so it doesn't look like HTML to some other stage of the parser that should ignore it), do some processing on the outer HTML, and finally replace all the keys with the original HTML?

That could be served just as well by generating a random string rather than a hash, if so?

Ex.

def _hash_text(s: str) -> str:
    'md5-' + sha256(SECRET_SALT + s.encode("utf-8")).hexdigest()[32:]

could be replaced by the much faster

hex_digits = "0123456789abcdef"
def _hash_text(s: str) -> str:
    'md5-' + ''.join(random.choice(hex_digits) for _ in range(32)) 

for a quick fix.

(Estimate says this will make markdown conversion 2.5X faster)

主要言語
Python
スター
2.8k
フォーク
459
平均マージ
2日 14時間
マージ済み PR(30日)
5

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

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

trentm/python-markdown2 のほかの issue

trentm/python-markdown2 の issue をすべて見る

似ている issue

Python の issue をもっと見る

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

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