Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

oslcquery speed up large --percontribution querying by parallelising query with processing of results from previous query

未关闭
#21 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
35/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
停滞
技术栈
python
领域
api, cli

调研方向

首先在这个 Python 客户端中定位 oslcquery 的实现和 --percontribution 查询路径。使用提供的 large-project 命令作为性能基线,然后验证结果处理与下一次查询存在重叠,并且在不更改导出结果的情况下,测得的运行时间有所改善。

由索引模型根据 Issue 内容生成。

描述

enhancement

One example doing counting of artifacts/module in a very large GC project with 1253 contributions containing 25886 modules and total of 6722401 bindings was spending about 50% of the time processing results, sequentially with the queries; if the processing can be done in parallel with the next query that's a significant speedup. Probably doesn't need anything more fancy/complicated than processing in parallel with the next query, but I suppose some more speedup might be possible with a controlled number of queries in parallel, at the cost of server load.

-q rdm_types:ArtifactFormat=jazz_rm:Module -s oslc_rm:uses,dcterms:title,dcterms:identifier

主要语言
HTML
星标
52
派生
32
PR 合并指标
30 天内没有已合并 PR

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

IBM/ELM-Python-Client 的其他 Issue

查看 IBM/ELM-Python-Client 的全部 Issue

相似的 Issue

更多 Backend & API Design Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。