 Here, when I'm using the network benchmarks, I can see that there is one or two seconds difference between the JGIT implementation and the GIT implementations. With that benchmark, I actually saw maybe half a second or less than that kind of a difference, that too with large repositories. Small repositories, it was almost comparable. But with this experiment, with each of the repositories, that is the Jenkins or the Ruby, the GIT and the JGIT, there is a two or three second difference with, for an example, GIT with Jenkins is taking 21 seconds per operation. GIT with, oh, I'm sorry, I'm actually comparing two different things. One thing I have to say is that I'm not going to use these graphs because I myself get confused where I'm explaining these graphs. I'm going to simplify them to much smaller, I'm going to break them down to much smaller graphs for individual tests I have. So the first test was basically just one fetch. With the second test, GIT redundant fetch benchmark, it's with two fetches. So 21 seconds per operation, 23 seconds per operation, basically means the difference when we're adding the second fetch to the equation. So the differences you're seeing in per second operations, the differences, the gain you're seeing is because we're adding the second operation in the equation, in the benchmark. So I'd say with the considerable increase I've seen is with the last one, is that is the JGIT with Ruby with the double fetches, it took 268 seconds per operation. And with just one clone, it took 256. But then again, there's a problem. The problem is the, yes, the error rate. And because we're averaging results, it's always dangerous because an extreme observation might skew the whole result. So that's one thing that this is one of the things main. Possibly I could use another metric than average. I actually have to look if I could look at something like median, median is not affected by the very, the large, if you have a large variability, for example, if you have a 500 MB repository, it usually takes 10 seconds to fetch it. But because of the network, because of the variability, it took 20 seconds and it skews the result too much with average. I could possibly use median, which that would not happen with the median. It would take the middle observation. So I would have to look on that. How can I, I would have to look at the metrics JMH provides. I've seen its throughput, then I've seen average, and I'll see the other one as well. Maybe we can choose a better metric if when we are talking about benchmarking operations over the network. So the claim that using a big repository, using a large repository, we could see performance degradation for JGIT with the redundant. I cannot claim that because the error rate, you can see error bar, it's high. But with all of the results we have, there is a second or a two second difference. And the profiling results I shared, I shared them in the platform sig meeting. I shared one result was erroneous because it had like a six, what did I, three or four minutes difference between the double fetches and a single fetch. That's not true. But the other experiments, all the other experiments showed me that there is a good five or 10 seconds latency added because of the second fetch. And one more hypothesis, kind of a hypothesis I have, which I have to ask you guys is that maybe I'm seeing here two or three seconds because I am running the operation in a JVM. I'm not running it in a Jenkins instance, but when I'm running it in a Jenkins instance, there might be some overheads which would be added, which the environment is different, basically, that's, but I also, I think I assume that with CLI get, the operation is independent, the instance, instances behavior. So with that possibility that, okay, with the Jenkins instance, the performance might differ, would be considered for JGIT, maybe in the first CLI get, that's something Mark and Fran, and you guys can confirm, I'm not sure about this, but it's something I actually, yes. I would not worry much about that because the bulk of the time spent in these Git operations, either JGIT or command-line Git is done on the agent in a workspace. And therefore the JVM on that agent is probably not heavily loaded doing other things. So I wouldn't be concerned about that specific one you just referenced. It's, yes, it's certainly possible that there are other things going on, but I don't think it's likely to alter one versus the other. Okay, because Mark, when I was profiling the Jenkins instance, the second Fajit was almost taking 10 seconds, the eight seconds, not less than that, but with the benchmarks I have right now, I'm seeing differences of one second or two seconds, not more than five seconds any there, there I can be. So maybe I need to put both of those results forward and we can then analyze. Yeah, I think the data you're gathering is good to report. And if we say, hey, I can't explain why the difference happens here, that I think that's still perfectly reasonable to say, I don't yet have an explanation for this data. Okay, I'll probably say that, I'll do that. Okay, so this was the second deliverable. First was benchmark, the second was the fixing the redundant fetch issue. The third one, yes, so the third one would be implementing performance improvement into the plugin. This is going to be our way forward as well. So the thing we know is that we're going to provide a compatibility switch to the users. I've shown you guys how we can put it in the configuration page. It's by default, we're going to enable performance improvement changes in the plugin. Someone, a user can by choice, revert to the old plugin if they want to. The second is the heuristics we were talking about, the repository estimated class. And with that, I also have, I think we're, the time is over, it's 8.30. So I think I'll probably write that in the channel if it's okay with you guys. Or if you guys are comfortable, I could discuss something. One more thing I wanted to discuss. Actually, I'd propose, go ahead. I've got the time. Others can drop off if they need to drop off. And you're welcome to describe it in Gitter as well if you'd like, Rishabh. So I'll just take, it's probably a minute. So this was the demo, this is the basic framework. Of course I'm going to add the things I have discussed and the graphs and the clear graphs, not the default graphs we get from the visualizer website. So I'm going to do that. And I'll share that as soon as I can. And you guys have the editors access to the slides. So right now it doesn't have too much content to edit but once it does, you guys can modify it and change it. So while I was looking at Git LS remote, so we have the method which is implemented in the Git client is called Git remote references. So I actually, I found a class called Git SEM telescope which basically is an extension point which examines a repository from a distance without requiring a local checkout. And that is exactly something we want to do. The examination might be different but the kind of examination we want to do might be different but it's a huge relief and help for me because there's something I can look up to and I can possibly, now the questions to the first question I would have with this class would be do I add my, the things I want to do in this class because it is, in a general sense it is examining a repository and estimating the size of the repository also can come under examining a repository. The only thing we would have to worry the biggest thing would be to not break the existing cases we have while adding those things. So if my changes or adding them would change the current status of the plugin, then to keep it in a separate class because estimation of the size might be, I don't know, it's not dangerous but I don't know if it could result in any kind of issues we have not thought about I could have a separate class for it but this seems like a great place to add those things. Now, the Git SEM telescope, I saw that this class is extended by, it's actually used in the abstract Git SEM source and to the basic understanding I have the Git SEM source is the implementation of SEM source the SEM API which is basically created for a single repository we have one SEM source as far as I know and we create a Git SEM object using abstract Git SEM source. This is like, this is the implementation to create Git SEM objects. That is what I've seen as of now the preliminary examination I've had on the class. So I can see here that the telescope is being used by abstract Git SEM source to get the remote references and I'm not sure what it is doing with it right now but it's using it. So I can do the same thing. The heuristics is the first one, the cache thing we could probably, we could have that and then with the APIs I have to first figure out if the information is correct or not and we're going to review since REST APIs are not used in the project you would have to discuss that as well but I can look at this class and make something similar. So I just need to know should I add my functionality to this class or make another extension point? So I am delighted you discovered this. Stephen Connolly will be delighted you discovered this and I think you fit its use model perfectly and I'm a little embarrassed that I didn't point you to this initially. Well done, Rashab. That's why I think it's my job Mark to explain. Well, you did a brilliant job of it so this looks exactly like what you need. I would assume, but again, this is from my inexperience I would assume that you want to provide an implementation of this thing and use it. I use that implementation to do that. You use get SCM telescope but you are welcome to add to it if that will help you. If this is not some, you're not allowed to change it. The person who created this class is in my world a genius. So you need to, he's absolutely fundamentally brilliant and so you should think very carefully before you modify this. My code looks like a mortal wrote it, right? It looks like somebody who is still learning, still struggling. Stephen who wrote this particular code is over the top brilliant in doing things. So absolutely, this is a great place to work and a great place for you to think about should I insert it here or should I create an implementation that uses this abstract class? And I'm not sure I'm the right one to guide you. Fran is probably much better suited or Justin in terms of deciding which layer you put it at. But you've chosen a brilliant class to look at and SCM telescope with its objective of getting information about a repository without a local checkout seems to fit exactly with what you're trying to do with heuristics, right? Yes, we'll take the cash if we got it because that's the most reliable. But if we don't have a cash, SCM telescope gives us a way to go looking at the thing and express that as a concept. Yes, ma'am. So, okay. So Fran and Justin, do you guys have any advice you would like to give me before I explore more SCM telescope? Yeah, I agree with Mark. I think this is a really good path a little bit for this. Like I said, I think also I think Mark I would play around with this and see what you might be missing versus what you already have here. And then I think placement and stuff would probably be a result of what the answers to those questions would be. Okay, that makes sense. Yeah, it makes sense. Okay, I'm going to explore this class more and then possibly the easiest thing for me to do would be to add the heuristics here. But we'll discuss that in much later, greater depth once I explore the class more. So, yes, thank you guys for giving your extra time and the time you guys gave usually. So I'm going to refine the presentation and then you guys can review it whenever you guys have the time. Now, how long is that? As I looked at your slides, I thought, wow, this is an hour or more of Rishabh talking. Do you know how long they're allocating to you to do the presentation? Do they give you an hour? Do they give you? I actually wanted to ask that question to you guys because I could not see anywhere where I did look at the demos for the last time but they were taking 20, 30 minutes but it varies with individuals but I'm not sure what is the formal allocated time maybe I'll ask Oleg. Well, I think Oleg just went on vacation today. So Martin, let's just ask the GSOC org administrators. I believe Martin Dianju will host the meeting on Wednesday. So we could ask Martin, hey Martin, I would go a different approach. I would say Martin, I think I should have about 30 minutes. Is it okay if I take 30 minutes? And then if Martin doesn't answer, you just do assume 30 minutes. I wouldn't go much more than 30 minutes just because I assume they've got other people who want to present. There are seven projects that need to present. I agree, I agree. Yes, Mark. I'm going to streamline the presentation because right now I was discussing a lot of things as well so of course I'm going to keep it under 30 minutes. That's what I thought as well. Okay. Great. Thank you. I agree with that. I think if I remember right, it was 20, 30 minutes last year. But yeah, that's to confirm. Okay, Justin. Okay. So I think we should, we can end the meeting now. All right, and I apologize in retrospect. I had not started the recording until about 20 minutes into the meeting. So the meeting recording is a flawed record of what we've discussed. Rishabh, you're doing great. Thank you. I'll post the recording, the pieces of the recording that exists shortly. That's okay. All right. And Wednesday, so we will talk whatever the day the presentation is, but we'll also have our usual session or does our usual session collide next week with the presentations? I think they haven't decided the exact timings for the presentation. And they are going to have it in two batches. So not all of the guys are going to present at the same date. They'll have it on July one and for July two they haven't decided the times but three students may be on the first date or three or four more in the second one. That's how it's going to be. All right, so we are currently scheduled the 30 minutes prior to that meeting. So the phase one demos will be 30 minutes, will be exactly after our scheduled time on Wednesday. Do we as a group of mentors want to meet on Wednesday or do we allow you that time to have final preparation without the mentors? We could either cancel Wednesday's meeting in favor of you getting using the time to prepare or we could have the meeting with the entire focus being 10 or 15 minutes of looking one last time at your material before you present. What do you prefer, Rishabh? Do you want to meet Wednesday or not? I think we could meet for 10, 15 minutes before the, it wouldn't harm to get a review before presenting. I'm okay both ways actually, I don't have a problem because you guys will review the presentation, Google slides and I think I've given a fair estimation of what I'm going to say. So if you guys think that it needs a review before the final presentation, then it's okay with me. Okay, let's do the meeting then. Let's do the meeting. You've given us the flexibility, I'm prone to say let's do the meeting, we'll talk one more time and we can always stop it early if we feel a need to stop it early. Yeah, I'd say if you have a meeting and you feel like you want to just prepare some more or maybe we do five, 10 minutes or something and say, okay. Sure, sure, good luck. Thank you. Thank you. All right. Okay. Thanks, Rishabh. Have a great weekend. Thank you very, very much. Thank you, guys. Thank you. Thank you.