{"thread":{"id":"28504","subject":"Thoughts on gitk's memory footprint over linux-2.6.git","startedAt":"2011-09-26T19:38:35Z","lastAt":"2011-11-11T16:04:27Z","messageCount":6,"participants":["Martin Langhoff","Elijah Newren","Felipe Contreras","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"176250","messageId":"CACPiFC+T1EZ1CSakQxsYZhsnHc-ZsN1-=tpoi-NaQSdpU5Yxkg@mail.gmail.com","threadId":"28504","inReplyTo":null,"subject":"Thoughts on gitk's memory footprint over linux-2.6.git","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2011-09-26T19:38:35Z","receivedAt":"2011-09-26T19:38:35Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"In an odd turn of affairs, I am managing a bit of kernel development,\nand even writing the odd patch myself. As usual, gitk is excellent to\nvisualize what's new in the tree when developers in the team commit\nand push new stuff.\n\nHowever, I find it extremely annoying over the kernel tree, due to its\nmemory footprint. It is not the only thing I am running, (Chrome\nBrowser, Gnome3, Firefox, many gnome Terminal windows, emacs), and\ngiven that I am looking at \"just a couple of commits\" I don't feel\nopening a few gitk instances should be problematic... except that it\nis.\n\nEach gitk instance wants to gobble up >1GB of memory! It really wants\nto show me the \"Linux-2.6.12-rc2(...)Initial git repository build.\"\ncommit.\n\nAren't kernel hackers hurting with this? This box blazes through a\nkernel compile, but only has 2GB RAM. Regardless of amount of RAM,\nfiring up gitk gobbles up >1G and untold CPU cycles.\n\nMy tk isn't really up to par, but... here's a stupid idea.\n\n - In start_rev_list, run git log into a tempfile, and concurrently\nopen the same file for reading, as fd\n\n - Read in a bound number of commits, say 10000 (\"just\" 200MB)\n\n - If we haven't made it to the end of the file, remember the offset\nand keep reading the file, counting matches of /^commit/ to get a\ncommit count and size the scroll back\n\n - re-activate the reading as required...\n\nThere are of course tricky aspects of concurrent programming at hand.\nI am not sure what concurrency model gitk has now, but it does a great\njob of not blocking and not getting confused.\n\nTricky Tk programming, or go buy some RAM? Yeah, I know.\n\nNow why didn't I pack that Tk book when I moved here?\n\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- Software Architect - OLPC\n - ask interesting questions\n - don't get distracted with shiny stuff  - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"176269","messageId":"CABPp-BHo5qKQVFRzFpoyt6dZZ3=UqVAtSjVy0uRDWnA+ASsBPw@mail.gmail.com","threadId":"28504","inReplyTo":"CACPiFC+T1EZ1CSakQxsYZhsnHc-ZsN1-=tpoi-NaQSdpU5Yxkg@mail.gmail.com","subject":"Re: Thoughts on gitk's memory footprint over linux-2.6.git","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2011-09-26T22:02:05Z","receivedAt":"2011-09-26T22:02:05Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Mon, Sep 26, 2011 at 1:38 PM, Martin Langhoff\n wrote:\n> In an odd turn of affairs, I am managing a bit of kernel development,\n> and even writing the odd patch myself. As usual, gitk is excellent to\n> visualize what's new in the tree when developers in the team commit\n> and push new stuff.\n>\n> However, I find it extremely annoying over the kernel tree, due to its\n> memory footprint. It is not the only thing I am running, (Chrome\n> Browser, Gnome3, Firefox, many gnome Terminal windows, emacs), and\n> given that I am looking at \"just a couple of commits\" I don't feel\n> opening a few gitk instances should be problematic... except that it\n> is.\n\nIf you only want to look at a couple commits, you could tell gitk that:\n gitk -N\nwhere N is some small integer -- or even 10000, as you suggest. Or\nuse other rev-list arguments, such as\n gitk v2.6.38..master\n\ngitk and 'git log' accept basically the same arguments, so look at the\nhelp for git log if you want to find other example ways to slice and\ndice what pieces of history to view.\n\n\nHope that helps,\nElijah\n"},{"id":"176270","messageId":"CACPiFCJvg4X7yL0FUYEtB4U4cabyczrHGDapTgLncFCoDF1EEQ@mail.gmail.com","threadId":"28504","inReplyTo":"CABPp-BHo5qKQVFRzFpoyt6dZZ3=UqVAtSjVy0uRDWnA+ASsBPw@mail.gmail.com","subject":"Re: Thoughts on gitk's memory footprint over linux-2.6.git","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2011-09-26T22:07:44Z","receivedAt":"2011-09-26T22:07:44Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On Mon, Sep 26, 2011 at 6:02 PM, Elijah Newren wrote:\n> If you only want to look at a couple commits, you could tell gitk that:\n>  gitk -N\n\nI know I can -- I've done my bit of git hacking but it was long ago so\nif you use your -N parameter you won't see it ;-)\n\nI argue that -n 10000 should be the default -- most of the time you\nopen git to see recent commits, not that 2.6.12-rc3 commit. Of course,\nit cannot actually be the default, because currently there's no way to\nscroll past that limiter.\n\nIt's a hard limit, and that's not useful.\n\nNow, git internally is very smart about using sliding windows over\nlarge datasets. The porcelain tools don't try to be so smart, but\nwe're at a point where, as a user, I really wish gitk had some of that\nmagic.\n\ncheers,\n\n\n\nm\n-- \n martin.langhoff@gmail.com\n martin@laptop.org -- Software Architect - OLPC\n - ask interesting questions\n - don't get distracted with shiny stuff  - working code first\n - http://wiki.laptop.org/go/User:Martinlanghoff\n"},{"id":"179312","messageId":"CAMP44s1cZc5OZ0L0zG-Wu+QVpu7xv4-JtWTBtPvnjO7sUFeM9w@mail.gmail.com","threadId":"28504","inReplyTo":"CACPiFC+T1EZ1CSakQxsYZhsnHc-ZsN1-=tpoi-NaQSdpU5Yxkg@mail.gmail.com","subject":"Re: Thoughts on gitk's memory footprint over linux-2.6.git","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-11-11T12:44:52Z","receivedAt":"2011-11-11T12:44:52Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Sep 26, 2011 at 10:38 PM, Martin Langhoff\n wrote:\n> However, I find it extremely annoying over the kernel tree, due to its\n> memory footprint. It is not the only thing I am running, (Chrome\n> Browser, Gnome3, Firefox, many gnome Terminal windows, emacs), and\n> given that I am looking at \"just a couple of commits\" I don't feel\n> opening a few gitk instances should be problematic... except that it\n> is.\n\nSometimes I do this:\n % gitk master..branch_1 master..branch_2 ...\n\nBut as I visualize more branches, it becomes tedious.\n\nIt would be nice to have --base option, and show only the commits\n...\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"179317","messageId":"4EBD2EFF.1010000@viscovery.net","threadId":"28504","inReplyTo":"CAMP44s1cZc5OZ0L0zG-Wu+QVpu7xv4-JtWTBtPvnjO7sUFeM9w@mail.gmail.com","subject":"Re: Thoughts on gitk's memory footprint over linux-2.6.git","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2011-11-11T14:19:43Z","receivedAt":"2011-11-11T14:19:43Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 11/11/2011 13:44, schrieb Felipe Contreras:\n> On Mon, Sep 26, 2011 at 10:38 PM, Martin Langhoff\n> wrote:\n>> However, I find it extremely annoying over the kernel tree, due to its\n>> memory footprint. It is not the only thing I am running, (Chrome\n>> Browser, Gnome3, Firefox, many gnome Terminal windows, emacs), and\n>> given that I am looking at \"just a couple of commits\" I don't feel\n>> opening a few gitk instances should be problematic... except that it\n>> is.\n> \n> Sometimes I do this:\n> % gitk master..branch_1 master..branch_2 ...\n> \n> But as I visualize more branches, it becomes tedious.\n> \n> It would be nice to have --base option, and show only the commits\n> ...\n\nWhat's wrong with\n\n gitk master..branch_1 branch_2 branch_3 branch_4 branch_5\nor\n gitk --branches --not master\n\n? (I do that all the time.) Recall that 'master..branch_1' is short for\n'^master branch_1'. It is sufficient to specify the negative ref, ^master,\nonly once.\n\n-- Hannes\n"},{"id":"179318","messageId":"CAMP44s2tjeQAq+WuAepwvcY74X1af_pPjH4PSbe-Q=OuuAucWg@mail.gmail.com","threadId":"28504","inReplyTo":"4EBD2EFF.1010000@viscovery.net","subject":"Re: Thoughts on gitk's memory footprint over linux-2.6.git","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-11-11T16:04:27Z","receivedAt":"2011-11-11T16:04:27Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Nov 11, 2011 at 4:19 PM, Johannes Sixt wrote:\n> Am 11/11/2011 13:44, schrieb Felipe Contreras:\n>> It would be nice to have --base option, and show only the commits\n>> ...\n>\n> What's wrong with\n>\n>     gitk master..branch_1 branch_2 branch_3 branch_4 branch_5\n> or\n>     gitk --branches --not master\n>\n> ? (I do that all the time.) Recall that 'master..branch_1' is short for\n> '^master branch_1'. It is sufficient to specify the negative ref, ^master,\n> only once.\n\nAh, nice! Thanks a lot :)\n\n-- \nFelipe Contreras\n"}]}