Verdict

“The approach is viable and aligns with established black - box performance modeling and learning - based scheduling, with differentiation hinging on robust, incremental model construction and error - mitigation.”

The idea is technically feasible: repeatedly executing a known binary against varied inputs yields enough telemetry to fit statistical or machine - learning models that predict execution time, CPU, memory, and I/O usage. Such black - box profiling is well - established in performance engineering, and incremental/online learning methods (e.g., stochastic regression, incremental decision trees) can update models as new runs arrive. Industry examples include workload profilers for video codecs, data - processing frameworks, and capacity - planning tools that use regression or ML on historical measurements. The main challenges are ensuring sufficient data diversity, handling non - stationarity (e.g., changing hardware or system load), and mitigating prediction error. Existing systems mitigate error by using conservative bounds, ensemble models, fallback heuristics, and dynamic re - allocation, which can be incorporated into the scheduler. While the approach is not brand - new - research on learning - based scheduling and empirical workload modeling already exists - the differentiation lies in per - operation model building and its integration into a distributed scheduler that continuously refines its estimates. This makes the concept viable and potentially valuable, though durability will depend on robust model updating, feature selection, and error - control mechanisms.

“The core profiling-modeling-scheduling loop is standard supervised learning with a telemetry pipeline - the real build risk is cold-start handling and generalizing feature extraction beyond one program type.”

This is highly buildable for a solo or 2-person team in 4-12 weeks. The core technical components are all well-trodden: (1) a profiling harness that runs known binaries with varied inputs and captures telemetry via cgroups, /proc, or container metrics APIs; (2) a feature extraction layer that parses input metadata (ffprobe for video, file stats, etc.); (3) a regression or classification model (scikit-learn, XGBoost, or even simple linear models) mapping features to resource predictions; (4) a scheduler that consumes predictions for placement decisions. None of these require novel research. The hardest parts are: (a) building a robust telemetry capture pipeline that works across different execution environments (containers vs. bare metal, different OSes), (b) designing the feature schema to be extensible across program types without overfitting to video decoding, and (c) handling cold-start (no data for a new program) gracefully. The cold-start problem is the biggest risk - a scheduler that makes bad predictions early can perform worse than a naive round-robin policy, so you'll need a fallback strategy (e.g., conservative defaults, gradual trust in model predictions). The online update loop is straightforward: append new observations, retrain or incrementally update the model. For v1, batch retraining on a schedule (e.g., nightly) is far simpler than true online learning and is sufficient. The video decoding example is a good test case because ffprobe makes feature extraction trivial and the input space is well-parameterized. The main scope risk is generalizing beyond a single program type - supporting arbitrary binaries with unknown input formats requires a pluggable feature extractor architecture, which adds complexity. But for a v1 focused on one or two known program types (video decode, image processing, log parsing), this is very achievable. The mathematical framework described is essentially supervised learning with feature engineering, which is standard practice. The idea is technically sound and the build path is clear.

“Building an incremental, feature - rich empirical model of a known program's resource use is feasible and aligns with existing performance - prediction techniques used in modern batch schedulers.”

The described approach is essentially empirical performance modeling of a known binary, a well - studied problem in systems research and practice. Repeated executions with varied inputs generate observable telemetry that can be fed into statistical or machine - learning models to predict execution time, CPU, memory, and I/O. Feasibility is high: many production systems (e.g., Google's Borg, Azure Batch, Spark's task duration estimators) already use historical measurements and regression or tree - based models to schedule workloads. Terminology includes "black - box performance prediction", "workload characterization", "empirical performance modeling", and "online learning for performance models". Construction typically combines feature extraction (input attributes, system state) with regression, random forests, gradient - boosted trees, or neural nets; sometimes Gaussian processes are used when uncertainty estimates are needed. Feature granularity matters: raw file size alone is insufficient for video decoding; codec, resolution, bitrate, frame rate, and compression profile are strong predictors, as confirmed by numerous video - transcoding studies. Online updates are feasible via incremental learning algorithms (e.g., online random forests, stochastic gradient descent, or Bayesian updating) allowing the model to refine itself as new executions arrive. Imperfect models are still valuable for scheduling because the goal is often relative ranking or risk - aware placement rather than exact prediction; schedulers can incorporate prediction confidence, add safety margins, or fall back to conservative policies when uncertainty is high. Error mitigation strategies include prediction intervals, robust optimization, reactive re - scheduling, and using ensembles to reduce variance. Overall, the idea aligns with established research and industry practice, making it a technically viable foundation for a distributed scheduler.

“Building an empirical, continuously updated model of a known program's resource behavior enables a scheduler to make data - driven placement and concurrency decisions that consistently outperform static heuristics for recurring workloads.”

The approach described is essentially empirical performance modeling of a known black - box program, a well - studied problem in systems research and practice. Repeated executions with varied inputs generate a dataset of input features (codec, resolution, bitrate, etc.) and observed resource usage (time, CPU, RAM, I/O). From this data one can fit regression models, decision trees, random forests, or neural networks to predict future behavior. Such models are feasible because the program binary is static, so its performance variations stem mainly from workload characteristics and runtime environment, both of which are observable. Academic terminology includes "black - box performance modeling," "workload characterization," "empirical performance prediction," and "online learning for scheduling." In practice, models are often constructed using statistical regression or machine learning techniques; analytical models are used when the program's internals are known, but for proprietary or complex binaries empirical methods dominate. Feature granularity matters: file size alone is rarely sufficient; domain - specific attributes like codec, resolution, frame rate, and bitrate are strong predictors of decoding cost. Online updates are feasible via incremental learning algorithms (e.g., stochastic gradient descent, online decision trees) or by periodically retraining on accumulated data. Imperfect models are still valuable for scheduling because the goal is usually to make better relative decisions - e.g., placing a CPU - heavy job on a less loaded node - rather than to predict exact runtimes. Systems mitigate prediction error by using confidence intervals, adding safety buffers, employing reactive adjustments (e.g., preemptive migration or throttling), and falling back to simpler policies when predictions fall outside trusted bounds. Overall, the idea is technically sound and aligns with existing work on adaptive, data - driven schedulers for batch and streaming workloads.

“The model will fail because coarse input metadata (codec, resolution, bitrate) cannot predict execution behavior for content-dependent workloads like video decoding, and the feedback loop will contaminate the training data with scheduling-induced noise.”

This idea dies from a specific, well-documented failure mode: the empirical model will be trained on a distribution that is fundamentally non-stationary and non-identifiable from the features you propose. For video decoding, execution time and resource usage are dominated by codec complexity, scene content, motion vectors, and bitrate variability within a file - not by the coarse metadata you list (codec, resolution, duration, bitrate). Two 30-minute H.264 1080p files at 10 Mbps can differ in decode time by 3-5x depending on content complexity (e.g., static talking head vs. high-motion sports). Your feature set cannot capture this, so the model will have irreducible error that makes scheduling decisions actively harmful. The second killer is the cold-start and distribution-shift problem: in a real batch workload, the input mix changes over time (new codecs, new content types, new resolutions). Your model M_n is only as good as the last n observations, and if the workload shifts (e.g., from H.264 to AV1, or from 1080p to 4K), the model will confidently predict wrong values for weeks until enough new data accumulates. During that period, the scheduler will make worse decisions than a simple heuristic like 'one job per core, FIFO.' The third killer is that the feedback loop you describe - predict, schedule, execute, observe, update - creates a self-reinforcing bias: if the scheduler places a job on a contended node based on a bad prediction, the observed execution time is inflated by contention, which then gets fed back into the model as if it were an intrinsic property of the workload. This contaminates the dataset and makes the model progressively worse. Existing systems (Kubernetes, YARN, Mesos, Slurm) avoid this by using declarative resource requests from users, not learned models, precisely because learned models are unreliable for adversarial or highly variable workloads. The academic literature on this (performance modeling, workload characterization, online learning for scheduling) consistently finds that learned models work only when the workload is highly regular and the feature space is rich enough to capture the variance. Your feature set is not rich enough, and the video decoding domain is too variable.