{"issue":{"title":"Depfile parser","user":{"login":"sorbits","id":11901,"url":"https://api.github.com/users/sorbits","avatar_url":"https://secure.gravatar.com/avatar/0077b96c5297042f41beb88042bf7232?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"0077b96c5297042f41beb88042bf7232"},"created_at":"2011-12-26T20:49:40Z","milestone":null,"labels":[],"state":"open","updated_at":"2011-12-27T21:06:20Z","id":2659865,"closed_at":null,"html_url":"https://github.com/martine/ninja/issues/170","pull_request":{"patch_url":"https://github.com/martine/ninja/pull/170.patch","html_url":"https://github.com/martine/ninja/pull/170","diff_url":"https://github.com/martine/ninja/pull/170.diff"},"body":"Now with updated tests, new test for escaped spaces, and `string` instead of `std::string`.","number":170,"url":"https://api.github.com/repos/martine/ninja/issues/170","comments":3,"assignee":null},"comment":{"user":{"login":"martine","id":3847,"url":"https://api.github.com/users/martine","avatar_url":"https://secure.gravatar.com/avatar/1d125552c92c317d4b00435a75848404?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"1d125552c92c317d4b00435a75848404"},"created_at":"2011-12-27T21:06:20Z","updated_at":"2011-12-27T21:06:20Z","id":3285232,"body":"Yes, my behavior around memory leaves a bit to be desired.  :(\r\nBut it has a reason -- I brought in StringPiece for performance benefits after code that made more copies worked.  (See the comments on the top of the class for a description of how its memory management is external.  I know it's a bit weird but it's a common class used within Google code, including Chrome.)\r\n\r\nI'm ok with needing somewhat of a global picture as long as the total picture remains small.\r\nI think my ideal end state would be something like:\r\n\r\n1. all files we read are either mmap()ed or allocated for the lifetime of the ninja processes\r\n2. all paths are pointers into that memory\r\n3. all allocations of graph state (Node/Edge objects) are arena-allocated.  (Currently they are allocated and leaked, but we could save some cost by making that more explicit with an arena)\r\n\r\nIn practice, none of this is too urgent, as Ninja is already \"fast enough\", and I don't like making optimization changes without a profiler telling me first that they will be helpful.  But the reasons for the current hacks are due to it not being fast enough in the past, so I'm eager to at least not regress.\r\n\r\nSo I guess my final point is: whatever you think is cleanest is fine, as long as you can demonstrate that it doesn't regress performance.","url":"https://api.github.com/repos/martine/ninja/issues/comments/3285232"},"action":"created"}