Albert Zeyer

> When you check that the `usage.run.1` file is indeed updated, do/did you check on the node of the job (cn-283) or on the node of the manager (indigo) or...

With current master (after https://github.com/rwth-i6/sisyphus/pull/84, https://github.com/rwth-i6/sisyphus/pull/85, https://github.com/rwth-i6/sisyphus/pull/87), I get this flame graph: There is `run_monophone_step`, and below `meta.System.train`, which results in `JobSingleton.__call__`. Zoomed in on this: Note that `JobSingleton.__call__` is...

> `deepcopy` also takes some time, and it's not really clear whether this is really needed. Ok, removing this gets me from 14 secs to 8 secs, so this has...

> > Although I don't really see why this is slow. > > But you plot shows why it is slow? Due to `os` calls. Or do you mean you...

Yes I looked at `os.path.join` already. There is some overhead due to the `fspath` calls, and also the `map`, also the `for` loop, also the try-except logic around it. But...

> I didn't expect os.path.join to be that expensive! In any case, it would be nicer to use `os.path.sep` instead of `"/"` (not that I would expect Sisyphus to be...

> > > `deepcopy` also takes some time, and it's not really clear whether this is really needed. > > > > > > Ok, removing this gets me from...

Isn't this also fixed now via PR #154 (fixing issue #105)?

You change two things here: * introduce caching logic * change `__lt__`, `__eq__` I assume the caching logic could break some code. Maybe some code sets the `creator` or `path`...

> You are right, the cacheing should be it's own PR and would need to be invalidated if `creator`, `path`, or `hash_overwrite` changes. I'll remove it from this PR. It's...