From 81216931c6faa4253d6c5c62295421df31450f17 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 12 Oct 2020 12:32:53 -0400 Subject: [PATCH] comment --- ..._21a2d5a3090a5bbdad413f2221b887b0._comment | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 doc/todo/memory_use_increase/comment_2_21a2d5a3090a5bbdad413f2221b887b0._comment diff --git a/doc/todo/memory_use_increase/comment_2_21a2d5a3090a5bbdad413f2221b887b0._comment b/doc/todo/memory_use_increase/comment_2_21a2d5a3090a5bbdad413f2221b887b0._comment new file mode 100644 index 0000000000..e497e5bb48 --- /dev/null +++ b/doc/todo/memory_use_increase/comment_2_21a2d5a3090a5bbdad413f2221b887b0._comment @@ -0,0 +1,28 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2020-10-12T15:42:31Z" + content=""" +That is good thinking. Since that commit, it has since been changed to use +a Chan. Commit bd2d304064915b3785dbd0725bf81643277530ec actually did think +about this a little: + + Chan will be faster than DList here. Bearing in mind, it is unbounded, + but in reality will be bounded by the size of the stdio buffer through + git cat-file. + +I added debug prints of all readChan and writeChan, and they seemed more or +less evenly interleaved throughout the run, although at the start +there were 274 writeChans before the first readChan and at the end +a similar run of readChans. That does not seem large enough to explain the +memory use though. + +Next I tried converting to a TBChan, bounded to 1000 items. Did not affect +memory use. Dropped the bound to 10 items. That actually hung, possibly +the pipeline needs to be fuller than that before stuff comes out the other +end? Also hung with 100 items. With 300 items, it ran, with the same memory +use. + +(Also noticed that the memory use is sometimes more like 225 mb, probably due +to differences in caching and timing.) +"""]]