Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Review extension boundaries and establish an architecture performance baseline

Open
  • Is something wrong?
#28 14 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
devtools, documentation, performance

Research direction

Start with devguide/ARCHITECTURE.md, ROADMAP.md, and devguide/validation/workflow_profiling.md; review the current-state claims against the listed design authorities and measured results. Inspect devtools/profile_workflow.py and its recorded methods and limits. Done means the current-state matrix, reproducible measurement method and limits, tracked concrete defects, and ordered smallest useful follow-up blocks are recorded, with future implementations kept separately scoped.

Written by the indexing model from the issue text.

Description

What

Review DockingMT's implemented extension boundaries against its existing roadmap and establish a measured baseline for a powerful, lightweight, fast scientific component. The user explicitly reaffirmed that growth must remain possible in several directions from the first implementation.

Existing authority and scope

devguide/ARCHITECTURE.md, DESIGN_PRINCIPLES.md, SCIENTIFIC_MODEL.md, SCIENTIFIC_HORIZONS.md, ROADMAP.md, and DECISIONS.md already distinguish scientific intent, backend, executor, domain/guidance/constraints, stages, runs/campaigns, and scientific records. This review turns those distinctions into a current-state assessment and a bounded next-step order. It does not authorize implementing all horizons or inventing empty frameworks.

Measured baseline

At 181000a4fd63b40d750fd739414fb651f5631fbc, Python 3.13.14 on local Linux, three fresh-process import samples give medians of 0.434 s and 65.24 MiB process peak RSS for DockingMT (656 loaded modules). Vina, MolSysViewer, RDKit, and Torch remain unloaded. MolSysMT-only control: 0.432 s and 65.30 MiB; PyUnitWizard-only control: 0.038 s and 20.26 MiB. This is environment-specific evidence, not a portable threshold or provider blame.

Synthetic result measurements, three samples per operation:

Poses Atoms/pose Rank median (s) Export median (s)
256 32 0.0404 0.0637
256 1024 0.0399 1.3793
1024 32 0.1307 0.2212

Ranking shares coordinate buffers in these cases; no coordinate-copy bottleneck was demonstrated. Export builds lists and copies nested snapshots, so growth deserves profiling without weakening #25's independence guarantees. These samples contain minimal metadata, do not represent a campaign or docking-quality benchmark, and exclude imports/construction from result timings.

Review outcomes

  • Preserve distinct backend and executor responsibilities; keep present local execution simple.
  • Introduce stage composition at the first concrete rescoring/refinement workflow, with stage identity, semantic score descriptors, and retained score/ranking history.
  • Keep native rich domains intact; declare adapter approximation handling and extend serialization when the first non-box domain is actually supported.
  • Keep molecular operations in MolSysMT and visualization optional; use adapters for TopoMT, PharmacophoreMT, and ElastNetMT scientific contracts.
  • Before small screening/ensembles, specify prepared-input ownership, identity, failure isolation, resource limits, and safe backend-specific reuse/invalidation. Avoid global caches over mutable molecular inputs.
  • Measure import, orchestration, preparation/projection, grids, native computation, normalization, and export separately. Optimize demonstrated costs while preserving scientific results and provenance.

Acceptance: record the current-state matrix, reproducible measurement method and limits, tracked concrete defects, and the ordered smallest useful follow-up blocks. Keep future implementations independently scoped and validated. No sibling changes or coordination are required for this review.

Phase-profiling implementation (2026-10-02)

The second follow-up block now adds optional VinaProtocol(collect_timings=True) provenance with ten consecutive adapter phases, explicit seconds and a monotonic clock. The default path allocates no phase recorder and reads no additional clocks. A repeatable fresh-process paired tool, devtools/profile_workflow.py, separates imports, problem construction, public docking, dictionary export, JSON encoding and file writing. It checks matching outputs, input identities and execution contexts, verifies captured input hashes and preserves recorded constraints/guidance.

Three enabled/disabled pairs per route retained identical scientific snapshots within each route. Enabled medians: molecular 181L input normalization 5.498 s, captured PDBQT 0.0109 s; affinity maps ~0.65 s, native docking ~0.32 s, automatic preparation ~0.274 s. Small-result export 0.00145 s / 0.000366 s. Negative enabled-minus-disabled median differences remain noisy observations, not a speedup or overhead bound.

Methods, environment/source identity, sample timings and limits: workflow profiling record. Final local validation: 354 tests passed, Ruff lint/format, report indexes and diff check passed; final paired captured-input CLI smoke passed. No sibling changes or coordination.

Status remains partial: larger representative export/local optimization and the next accepted extension contract are still separate follow-ups. No cache, generalized executor, science qualification or portable runtime gate is introduced.

Dominant language
Python
Stars
1
Forks
0
Avg merge
30m
Merged PRs (30d)
1

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from uibcdf/dockingmt

All issues in uibcdf/dockingmt

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.