On 7/14/07, Junio C Hamano <gitster@xxxxxxxxx> wrote:
"size" is a bit vague here. What if we later want to extend things so that you can ask for the entire log entry size including the patch output part (I am not saying that would be an easy change --- I am more worried about the stability of the external interface). So is --show-"size". "message-size" would have been a bit easier to swallow, but I sense the problem runs deeper.
What about --section-sizes? You can add in the output line all the sizes you want, message, patch and future extensions separated by a space. An example output for message and patch sizes. sizes 456 565\n Or, as a stream friendly alternative (and also more elegant) you can output 'section size' before each section, so as example commit d9e940.... section size 456 < log header and message body> section size 565 <patch diff content> section size 232 <other type of content>
I have a more basic question. If you are reading from non "-p" output, where do you exactly have the wasted cycles in your reader's processing?
qgit loading works like this: git log output is read as a series of big binary chunks by a Qt library function that calls read(), these chunks are read each one in a different buffer and there they stay for all the application life time (or until a data refresh), so there is no copy of data in qgit, the buffers are allocated and the pointers passed to read(), that's all. It's a kind of software DMA ;-) The only information that qgit needs to infere at startup is where to find the first line of each commit, for parent information and revision's counting, all the other data is read and consumed only on demand, i.e. for showing to user, but because only the screen visible part of the list is needed, data is read from these buffers and parsed *in small chunks* and only when user scrolls the view. The problem is that to get the first line of each revision the message boundaries of _all_ the commits must be known/found. Because currently there is no message size information the application have to: -get the offset of commit first line -try to find the delimiting '\0' if existing (binary chunks could be truncated at any point) -get the offset of commit first line of next revision -and so on for all the revisions Finding the delimiting '\0' it means to loop across the whole buffers and _this_ is the expensive and not needed part. If just after the first line would be possible to point to the beginning of the next revision this seeking for '\0' would be not necessary anymore. When user asks for data of revision 'x' then because offset of revision 'x' is known, application could just point to the correct offset in the correct data buffer and parse out the (small) needed info. Hope I have explained clearly enough, I have some problems writing in at late evening ;-) Marco - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
