{"thread":{"id":"58103","subject":"[GSoC] Abhradeep's GSoC blogs (5 Jul, 2022 IST)","startedAt":"2022-07-04T19:36:50Z","lastAt":"2022-07-04T19:36:50Z","messageCount":1,"participants":["Abhradeep Chakraborty"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"458456","messageId":"20220704193628.76595-1-chakrabortyabhradeep79@gmail.com","threadId":"58103","inReplyTo":null,"subject":"[GSoC] Abhradeep's GSoC blogs (5 Jul, 2022 IST)","fromName":"Abhradeep Chakraborty","fromEmail":"chakrabortyabhradeep79@gmail.com","sentAt":"2022-07-04T19:36:28Z","receivedAt":"2022-07-04T19:36:50Z","isPatch":false,"sender":{"key":"chakrabortyabhradeep79@gmail.com","avatar":"https://avatars.githubusercontent.com/u/75240995?v=4"},"body":"Hello developers, this is the thread where you can know about\nmy weekly GSoC blog links.\n\nMy Project - Reachability bitmap improvements\n\nBlog update\n------------\n\nTitle - GSoC Week 3: working on further improvements\nBlog link - https://medium.com/@abhra303/gsoc-week-3-working-on-further-improvements-13a27db64cd5\n\nSummary -\n\nIn this week, I continued to work on further improvements of \nThe bitmap-lookup-table patch series. Some of the requested\nchanges are (1) Improve the documentation and fix typos (2) add\ncomments (3) Disable `pack.writeBitmapLookupTable` by default\n(4) Fix alignment issues (5) Make a `bitmap_lookup_table_triple`\nstruct (6) Subtract the table_size from index_end irrespective of\nthe value of GIT_TEST_READ_COMMIT_TABLE.\n\nAfter implementing all the requested changes, I started working\non the idea I mentioned in my previous blog as my next step. The\nidea is to stop the xor stack filling loop if the current xor\nbitmap is already stored and assign `xor_bitmap` to it. As this\nbitmap is already stored, we don't need to iterate further as we\nknow all the other bitmaps that are needed to parse this bitmap\nhas already been stored.\n\nMy next step is to roughly implement roaring run bitmaps and\nrun performance tests to check if it's really worth it.\n\n\nPrevious blogs \n---------------\n\n-------------------------------------------------------\nTitle - GSoC Week 2: redesign the table format\nBlog link - https://medium.com/@abhra303/gsoc-week-2-redesign-the-table-format-829dae755a5\n\nSummary - \n\nIn the last week, I worked on the reviews. Some major requested\nchanges are (1) Use commit positions instead of commit oids in\nthe table. (2) Use 8 byte offset positions instead of 4 bytes\n(3) use iterative approach for parsing xor bitmaps (4) Use\n`<commit_pos, offset, xor_pos>` triplets.\n\nWhile implementing these changes, I discovered some bugs in the\nprevious version. I faced errors during this time. But finally\nmanaged to fixed those errors. Taylor helped me to get rid of\nsome errors.\n\nI think that we can optimise the parsing of xor bitmaps further\nby stopping stack filling loop when we get an already parsed\nbitmap since we know that bitmaps having xor relations with it\nhas already been stored/parsed.\n\n------------------------------------------------------- \nTitle - GSoC Week 1: Let's Get started\nBlog link - https://medium.com/@abhra303/gsoc-week-1-lets-get-started-fad78ec34dcf\n\nSummary -\n\nThis is the first blog that I wrote for GSoC. Taylor\nsuggested that I should work on \"integrating a lookup table\nextension\" first as it is smaller compared to other sub-projects.\n\nThe idea is to have a table at the end of .bitmap file which\nwill contain the offsets (and xor-offsets) of the bitmaps of\nselected commits. Whenever git try to get the bitmap of a\nparticular commit, instead of loading each bitmaps one by one,\ngit will parse only the desired bitmap by using the offset and\nxor-offset of the table. This will reduce the overhead of\nloading each and every bitmap.\n-------------------------------------------------------\n"}]}