avoid extra copy on load of tree sequences? about slim

[petrelharp]

The first step, though, is to update the tskit code.

[bhaller]

Oh, did that improvement not already get rolled into SLiM? I thought this got fixed quite a while ago now. Well, do a PR to bring SLiM up to the current tskit whenever you want.

[petrelharp]

It did get updated! But, there's been movement since then...

[bhaller]

I'm pretty sure this has been fixed; not sure why it didn't get auto-closed when the tskit PR was merged. @petrelharp, I'm closing this issue; please reopen if it has not in fact been fixed.

[bhaller]

Yes, this could probably be fixed. The memory spike shouldn't be much larger than the size of the .trees file being loaded, though, right? So unless you're working with really huge .trees files, this is unlikely to be a big deal. But it'd be nice to fix it just for polish, in any case.

[bhaller]

Hi @petrelharp. What's the status on this? I'm starting to think about releasing SLiM 3.4. Should a merge from tskit into SLiM happen before that happens?

[petrelharp]

I haven't done anything about it yet, and won't be able to get to it immediately. So, I'd like to do it, but not sure I can promise it.

[bhaller]

OK. If SLiM 3.4 ships without this, that seems fine to me; I'm not aware that anyone actually cares about it. Let me know if you'd like me to wait, though.