uh hello again folks. It is great to see you all here. Please post your questions to chat. I will check them all in the end of the session. Today we are talking about intelligent idea performance, how it improved in previous years, especially last year, what we did, why, and how. Also, I will tell you more of our plans and what we're going to do next. I will try to tell you some stories about how some performance improvements happened and what we actually did to overcome some performance issues. First thing I would like to cover and tell you more about how we actually estimate and try to measure problems and their impact on your life, and what we do to understand the real impact on users and what we have in our Arsenal to cover common problems. First of all, if we go to intelligent ID itself, let me open it for instance for a second. Here we have intelligent idea. You know it is a

jvm application. It is running on top of Java, namely CH Brains Runtime, which is a build of OpenJDK, and that is still a Java application. In 2024, it runs on Java. So we also use Java for IntelliJ IDEA development, not only develop features for Java, but also using Java and JVM languages on a daily basis. In this application, we actually have a pretty big number of metrics and measurements that we collect in order to measure performance and impact on your life. If we, for instance, open logs or folder here, we can quickly find interesting files here on indexing, diagnostics logs, open delimiter matrix, and so on. We also ask you, dear users, to help us with measurements and statistics and usage data. So if you see a notification inside IDEA which suggests you to share some usage data with us, you should know we do this. We ask you for feedback and usage data in order to improve performance in the first place.

data usually helps us a lot to find, identify, and fix real performance issues. So, most of the real-life problems such as freezes, lags, or some exceptions are reported by you or users who accepted such notification and functionality and who help us with your usage data. So, like many, many users actually share usage data with us. We do not do this automatically, so if you would like to help us, you can share your usage data and help us with that. Now, let's go back to the metrics and how we actually use them, how we use this usage data in order to measure some performance problems. One of the common metrics that we use, obviously for many processes such as highlighting, indexing, completion, and logs, and many other parameters, is Optics. It is a commonly used approach called application performance index, and it indicates some kind of performance status. It reflects user satisfaction with the duration of application processes. For instance, if we talk about completion

uh, we could uh estimate this UPS index uh for the first item shown in completion popup, or maybe for uh the entire uh PO uploaded, or even maybe for the time which takes to choose uh some item and completion popup. And abex operates on uh expert-defined uh ranges, so we should define some kind of um the best possible uh time, which is uh excellent for completion popup, for instance, and then we try to derive other ranges such as excellent, good, fair, poor, and unacceptable from this like best possible time, and estimate that. And on the right, you can see uh example of such abex metric. Change it over the time for different languages. In the past, it was uh like two years ago, or even more already, uh for different languages. For instance, for Python, uh we had perfect excellent completion UPS, and for Scotland, we had some, you know, worse experience that we would like to fix and improve in the future. And UPS shows like exactly this. Uh, we operate with expert-defined uh ranges, and we have these categories, and what is important

here is that uh we uh like collect a lot of metrics for many users for many completion events here, and then we try to uh understand uh how they all uh feed into this, but it is only for uh the approach where we Define uh ranges like from our expert knowledge or from our observations, maybe from feedbacks or from other stuff. Uh, there's more uh like important approach that we use that was introduced by our data analytics team, uh called Mega object, and mega objects is something uh that we uh like use to estimate how we usually improve the deals situation for real life users, because Rangers and like uh this events are based not on our expert like data or our exper expert opinion, it is based on real life metrics and on real life data, uh related to uh users who uh leave our products or still use it, so it is proven by usage data, and this is why we actually ask you to share such performance data with us, because based on this, we can estimate the real impact of improvements of performance improvements on your life, and here's the

uh basic schema uh on the slide. How do we uh estimate some data? We get some uh logs from you, then we uh try to uh use specific optimization methods of which our data analytics team uh use to uh like have these groups of users and events. And then we try to use this formula to uh infer exactly one number between zero and one, which shows exactly the status of some uh feature and its performance on real-life scenarios and users. This is how we actually can um um like see if our improvements uh convert into real-life uh changes that are visible to users and that like you will see in your ideas and improve your life in the end. Okay, uh now uh let's proceed to uh how it looks for us in the end of the day. Uh, we see here, for instance, Mega objects for startup of intell ID ultimate, for various versions from 2021.1 and to 2023.2. You see, uh, like we improved a lot from the uh Point 0.85 and up to uh 0.94, which is almost excellent, uh as our

users see it uh in the last summer version and that's how we actually know that our improvement like really converts into visible improvements for our users. That this, you know, ranges and liners, they go up all the time. Uh, I would like to say a huge thank you to our data analytics team and especially to data analytics working on performance for us because without their effort and without their input and work on mega obes and ranges, we would not be able to see our impact on your life and your daily routine in real life scenarios. So thank you folks for working with us. Okay, next topic is what do we do to understand what goes wrong. For instance, if you come to us to our issue tracker and say like, hey folks, I have a performance problem here, there are tons of freezers or there are some performance issues or there are, I don't know, some slowness in the editor and so on. Uh, we now use open imetry as a standard API for performance metrics.

that we uh like like really log a lot of performance metcs in this uh format, and uh push those to logs folder. So, if we uh open once again this uh logs folder, you can see uh CSV files, uh like regular CSV files. You can even open them. There are a lot of different numbers with lots of lots of strange uh names in there. Those are uh numbers from ID function, and there is also HTML file, which can be used to visualize uh such reports. Uh, you can use it also to see what we actually log, such as jvm memory, or CP usage, or maybe virtual file system uh synchronization, and so on. And nowadays, open limit is a commonly used format for such detailed uh metrics that we collect. And this is how you can actually help us with investigations and with performance problems. You could uh just archive this folder with all this stuff and attach to the issue, so we can uh understand uh the context and problem better in issues. Uh, op Li is great, quite nice library and API, which we use. And also quite important that we

can visualize results in many ways. Okay, uh, now, uh, I would like to proceed to stories because I promise stories to you. Let's, let me tell you some and, uh, tell you how IDE evolves and solves crucial, uh, performance problem in your daily scenarios. And we start with startup for sure because, uh, first of all, in order to use our product, users have to start it somehow. Uh, and let's see, I have, uh, IDE up and running here. Uh, let me clarify a bit, uh, about IDE and what we use nowadays. As I mentioned, Intelli it is a JVM application. It runs on Java. It is still, it still uses Java's SN for UI. So you can spot, uh, that we actually customize it a lot and we have new UI nowadays, but still it is not based on any other, uh, UI library. Still, well-known Java Swing but with many improvements in look and feel and many improvements in JVM itself. Uh, we have a team, uh, J Bra and Time Team, uh, fol who work on Java internals and patches for many Java

subsystems that are required for our UI and for our uh work on different platforms. That is why we can uh also use more modern mechanisms such as metals on M or veent or Linux on Linux, for instance, um because we also invest heavily in JVM development and try to apply uh recent latest patches and uh also collaborate with many folks on OpenJDK, uh to fix issues that we have on ID. And when you start your application, let's back to Startup, we actually have to start JVM itself as a binary, as a native application, which will load all our subsystems, a lot of jars, uh then locate class files there, then instantiate all the plugins and start loading. So for instance, if we uh restart our app, let's see how it looks like, uh nowadays. Okay, oh, I have a debug version, uh and let's see how it looks, uh for you. Uh, I have a fresh, uh version out of EP program, so we can also check our Early Access program for IDs. Uh, okay, where we're heading, oh.

we started much much faster, and you see uh that we actually opened I and show you uh code right away, and you do not see any uh indexing and uh uh. We also loaded all the line markers right away, and many things uh changed recently, uh but last year we had a lot of problems with startup, which we tried to solve, and now I will tell you uh which ones and and how we tried to solve them uh. The most uh uh like the oldest problem for us uh would be depend injection and application components. Many years ago, IntelliJ IDEA used a special dependency injection mechanism called components, such as project component or application component, and we also um supported depc injection via Constructor injection in components, so you could uh Define a Java class, um then mention this Java class in a special uh descriptor of a Plugin or of ID itself, and this component would be instantiate at startup when IDE loading. And what does it mean actually for us is that in order to even start IDE, we had to instantiate all of those application components from all plugins, which is

kind of evil. We have to load all the classes, and we have to create them. We have to load all their dependencies like classes they depend on, and also we have to use right order for construction injection. This led to huge problems with startup, and because of this, we cannot easily start and optimize H paths. Nowadays, it's all gone. Last year, we got rid of all the application components in our code base, and we now always avoid that. Instead of dependency injection and Constructor injection, we use a simple pattern called service Lo instead. On the right, you can see such service defined in our codebase. For instance, it is a simple class which receives a project in Constructor and annotated with annotation service. In order to use that in code, we ask a project for this service by class like Service like project got get service and my project service. And what it means is that we can instantiate such Services lazily on demand and not on Startup anymore. And this is how we

actually now uh build our ID and plugins uh in all the places. We no longer have um Central V injection mechanism, but instead we always ask for services uh when they are needed actually when we uh try to use them uh and that's how we actually uh improved startup a lot because there are no longer uh inefficient dependency management and we can easily optimize hot paths and use lazy loading here uh here I also would like to mention our uh change of our startup to parallel uh before like last year or maybe year before uh we used to have um a special interface for plugins uh to start some activities on the project opening and such uh interface was first of all blocking like it was a call uh which have to do all the work and then get back to the platform and also it was the process was sequential we have to um ask all the plugins for uh such uh class U call them one by one and only after that we could proceed to some project opening inside ID and this was changed dramatically last year we Rewritten all the uh startup activities.

and startup code of plugins to asynchronous parallel concurrent uh API, which is based on qu routines. If you uh do not know about about qu and cortines, you can learn more on Quin l.org. It is a special way of doing concurrency on JVM, uh which is uh like heavily based on idea of continuation and some asynchronous computations that um run not on threads exactly, but on some special obstruction, and which use uh suspend fun functions as a based as a based primitive, a special kind of functions that uh can be suspended, that can be uh like uh waiting for something without uh holding thread they're running on. Uh, I will not dive into details on cortines today because it is a much broader topic, but mention to you that we written all the plugins, and now our startup process is heavily paralleled, uh like bucked a lot, and all the plugins, they start their code in a concurrent manner. And we have such uh suspend modifiers for functions, uh that uh run in setup process, which improved startup process a lot, uh and the final uh point for uh

startup activities is CL loading uh. We have a lot of plugins out of the box, and also a lot of third-party plugins, and we know that they bring a lot of code. And they have a lot of extension points and lot of actions panels inspections, and so on. And this cost us real uh time during startup because in order just to execute the code, we have to load 50,000 uh class files from jars from dis actually, which is not f. And because of the reasons I mentioned, because of the parallelization and because of the improvements in this area, we also now uh can load those classes finally in parallel uh, which improves situation because we no longer uh do this uh in blocking Manner and uh. Also, cores allowed us to do this not uh on event dispatch thre, but we get back to it uh soon. I will tell tell you more of uh swing then dispatch thre and uh lcks in there uh. So we also improved the station with loing classes on jvm a lot, and we have a special charts and a

special metrics in this area. Let me uh show you maybe some some uh data uh for here. Uh here I will try to show you some uh real tool that we use in intellig ID team. Uh called IG perf. It is basically a dashboard of all the performance metrics for our performance tests. We have them a lot uh we have a lot of test nowadays and here we can see uh many many metrics such as for instance uh loading classes like how many classes do we load. And also we can spot some degradations and we can also analyze uh some specific uh types of classes such as lambdas or in lines or maybe method handle classes and so on. And uh this is usually how we spot some degradations. Uh we detect them automatically put red thing here and we can analyze that uh yeah we also use special kind of uh profiling for right let's get back to uh the slides. We use your kit to profile class loading. Your kit is great it shows uh not only loaded classes but also uh stack traces and places where they

loaded uh indexing. I already mentioned in the beginning of session that indexing is kind of the most uh mentioned problem common problem that people uh mention for our products. Let me tell you more of how we improved this uh in the recent previous year last year. Uh first of all, uh thanks to uh many uh people working on indexing team and also in product teams, uh we improved multithreaded indexing a lot like 25% improvement was achieved uh last summer, and we now no longer waiting for uh logs, uh our internal logs during parallel uh scanning and parallel indexing. Uh here in the picture you can see many many many small red dashes. It is an illustration actually for the indexing process where many uh scanning threads interrupted and waiting for some internal uh locks that we had. This problem now is gone, fix it and improve it, and we observe a huge 25% improvement on our huge moner where we called intell IDE itself and have a uh code for all the jet brains IDE products. Uh not only that, uh we also

changed a bit how we deal with various build systems. I know maybe some changes may sound strange and uh also uh not everyone likes them uh but we disabled downloading of source code for Gradle sync uh the same as uh was like done for Maven for many years. Maven users do not struggle about that and they download uh sources for libraries on demand, but for many years for Gradle we had to download sources of libraries always and couldn't do this on demand. Last uh like previous release 202 3.3, we disabled automatic downloading of sources for those libraries. So, in case you uh search uh uh and navigate to such uh library classes, you'll see uh such blue panel where you will be able to do this, basically the same as it was for Maven. And this change actually improves uh not only like the loing part of sources, yeah, it also greatly improves uh time for indexing of sources. For instance, on Spring Boot project, I mean to project itself a huge project available on GitHub, uh this to improvement of

50% faster indexing on Spring Boot project. So, you should not wait for indexing all those. It doesn't affect like searching for classes, methods, and many other usage searches. It may be sometimes. It could be inconvenient in different scenarios, but we are improving usability and UI in this area to make it more like easier for you to attach such libraries one by one and do not wait for indexing of all of them because indexing not only means spending time on indexing itself. It also means that indexes, which are files on disk, would be bigger. It would be slower to search through them for many things you would like to do in ID such as usage search, completion, or maybe some quick documentation stuff. So, it also improves the situation for many other applications. Okay, and finally, this release we focused on actions which are available while ID indexes things. We improved search for classes and symbols. We improved completion. We enabled run actions during indexing. And now if we go and compare different versions of ID.

before and uh the release, we are preparing for you now. You would see a difference clearly so it has the same uh like state of id. Id is still indexing code like it does some skying and indexing but before you saw this like not ready and seem not highlighted even and now you'll see the you'll see that everything is highlighted and seems ready. And also, we are improving running experience so we would be able to run tests and applications without waiting for indexes to complete and and not only that last year we improved scanning and indexing processes so we no longer uh start indexing and we no longer uh show any progresses uh because of that if you change nothing basically in the previous session so in case you just restarted ID or you go to work in the morning start your start your ID and open project from uh the yesterday like place we will no longer show you uh scanning progress because it is not important and we can do this synchronously finally and we will not disturb you and ID will be

ready right away. Like you will be able to see all the functionality, use that. Uh, go to classes, run them, completion will work, many things will be available right away. If um, ID configuration has not changed and plugins has not changed and you basically have the same ID as yesterday. Uh, I think this one of the biggest improvements in the perception of our products and uh, please try our AP version and let us know how do you feel. Uh, now and uh, what like, uh, what you can now do and do not wait for indexing to complete. Uh, okay, completion. Uh, in this area, uh, I would say that many improvements were achieved because of traditional profiling fixes and improvements but one improvement, namely in Ctland, certainly stands out. Uh, I would like to, uh, say huge thank you to our, uh, machine learning team who employed machine learning methods to improve completion actually. Uh, not, not, uh, teaching some AI stuff, not teaching some ML, uh, to provide some answers in chat but employing ML techniques to reorder some, uh, completion code prioritizing most relevant. Uh

contributors in completion, which resulted in improved not only up scores but also improved Mega up score on real-life user scenarios. And we see how it improved from poor to, uh, like good enough, and, uh, you could also spot the difference, uh, before even like changing any logic. So the entire change was to prioritize, uh, completion contributors, which find and show you some completion items based on a specific machine learning model, which can do this correctly and improve and prioritize more faster, more relevant contributors, uh, on like some less, less relevant, less performant ones, uh, yeah. So you could also spot this was this, uh, last December, okay, uh, what else highlighting, obviously, because you know U many people struggle a lot because of the slow, uh, highlighting in the editor, and they, uh, complain a lot that, Oh, it is slow while why I'm waiting for it, uh, and what does it take to highlight this Java file, uh, well let me tell you some stories about highlighting. We also fixed, uh, a lot of problems in there, but some are

certainly interesting. First of all, we introduced crashed editor markup like subsystem, which crashes all the highlighting and line marker. For instance, on disk, so when you start your ID again, they would be shown immediately and you would not wait for it. On the picture, you see analyzing is still shown that we not even started to run any highlighting here, but we already see line markers highlighting here, all the annotations highlighted and so on. So you can easily spot this in ID, like when we just reopen files, we no longer see any delay in highlighting. It is also based on this, we show you all the cachet data if file has not changed from the previous session and we start new highlighting session asynchronously in order to, you know, update line markers, inspect some maybe colors and so on. So you could see this Improvement also in 2023.3, great Improvement, thanks to our intell platform Team. What else, let me tell you.

a story about uh uh one of huge problems about indell idea and code um also couple of years ago maybe uh slightly less we spotted such problem on the right you see part of the code highlighted and part is not yet and even black and nothing seems working and highlighting is stuck what went wrong uh here many problems uh like the found first of all we realized that Java highlight Java highlighting in order to highlight something in order to highlight annotation or uh references here visits all the references inside Java elements and here by coincidence inside query attribute there are references to hibernate to hql query uh like Parts uh entities attributes and so on and in this example Java highlighting we're trying to uh find and visit and resolve and and find source I mean of uh such hibernate jpql attributes which led to S such Frozen Hing because finding source for hibernate attribute for instance is not cheap process you have to build uh jpa model understand which ches do do we have which attributes used you have to

find some hibernate mappings and entity classes and so on. And we realized that this like problem actually caused by quite the old problem that back then in 20 I don't know 2015 for instance, uh, there was a language, uh, which can be mixed with Java and which used Java constructs inside the, uh, internal strings inside the, uh, like parts of strings. And it is called Google web toolkit. Maybe you heard of it, maybe you remember of it. It is kind of Java for web, which enabled you to build, um, Java apps for the browser, compile Java to JavaScript, and so on. And in order to fix some issues with, um, find usages, maybe highlighting there, we introduced such U correct measure that would visit, uh, expressions and, uh, code inside Java's string literals and try to find their source. And it is actually causes a lot of troubles and problems for regular Java development, such as gql, for instance, or SQL or something else. So straightforward fix would be, uh, to limit such logic only for Google web toolkit language and do not try to do this for

regular Java code and it is not needed. There are many more problems found during this investigation, but they are less interesting, I guess, and we can admit them for today. This is like it was a huge, I would say, performance penalty. I'll show you this screenshot. It is a screenshot from a real-life project of a company called Kiloo. You can easily locate this code in their GitHub repository. We actually really like this project because it shows all the real-life problems, all the real-life struggles, and performance problems, especially because it is quite a big real-life product. So thanks to the authors of it. The next problem probably exists for many years. It is about JSON files, YAML files, and files that are connected to some JSON schema. You probably know of JSON schema. It is a special standard for JSON configuration, which enables you to have some validation capabilities, some completion highlighting, and

other stuff in editor based on a specific special definition of document called Jon schema, and we had a specific issue with one of Jon schemas attached to Jon files, namely Azure pliance schema. It is quite a big, quite a huge, I would say, schema with many, many, many, uh, other attached, uh, let me show you attached schemas. So if we try to open it, we can easily find it is not only big but also uses a lot of references to other documents. And finally, if we would try to, uh, combine, uh, one Jon schema for this one Jon file, I would say for such schema, it is quite huge. And the problem was, uh, for us is that, uh, back then before the any improvements, uh, we used our own lexer and parser and PSI structure to load such files. And what I should mention here is that, uh, ID lecture partial capabilities and so on in ID optimize for editing experience, not for parsing performance, not for some kind of batch, uh, processing or some B bch like improvements. We optimize our parser for incremental updates for some navigation, uh, indexing.

and many other uh things, and uh what it does to The Jone, and uh this issue is that it is pretty not optimal, I would say, to parse such huge gon documents with our own lecture and parure capabilities in intellig idea, and because of this, uh when uh users tried to use this Azure pliance schema, they had quite a huge memory allocation in their ID, like 20 gigabytes of memory traffic, um only to open a file, maybe small one file, which uses such sound schema, which is a huge problem not only because of the slowness of the process, but also because of the garbage collection, which is like, uh, caused by such a huge amount of garbage generated in the process, and uh, and finally, I I would highlight here that we finally fixed the problem, we switch to Jackson parer in this, uh, like area, uh, it improved the process of highlighting and completion a lot, what for instance on this test on a real end-to-end test, which opens, uh, a file using this Azure pipel schema, and highlighting it, and calling completion.

capability in there. We, uh, like observe change in, uh, inspections run from 18 seconds down to, uh, one and a half, which is huge Improvement. If you struggled before with some just documents or yaml documents, uh, I would encourage you to try our EP version and see if it improves your life actually. Uh, I would expect that, yeah, it improves freezes and LS. Uh, maybe the last, uh, thing, uh, where we have many improvements recently, uh, let me, uh, tell you more about, uh, what do we have under the hood. In idea still uses swing, as I mentioned, and one of the implications here is that it uses a single event Loop, single event dispatch thread. Here's the illustration, and we also use a special, uh, lock, special read right L implementation, which allows us to have one writing thread which changes, uh, the, uh, world, I would say, in our meaning, and also many read threads which can run in parallel if there are no paining rights or parallel rights. So right is kind of exclusive operation, which runs without any parallel activities, and reads can be

parallel. If there are no rights, and also we have a special kind of read which performs read and does not allow rights to start, which is useful in some specific cases. And because of this, we have a huge problem with freezes and a huge problem with lags because of the old, quite outdated code which does some heavy computations, heavy like changes on this event dispatch thread, and causing the issues with responsiveness of ID. So what we improved here, let me highlight that last summer we implemented, or maybe fall, we implemented a faster, stronger, better update of actions, menus, and context menus based also on Kines. So now you can easily see that opening context menu is no longer a pain. It is actually fast, like immediate, without any progress shown. You do not see any spinners and waiting for it. And also main menu is fast as hell because we now are able to run update for actions in parallel and also compute if they are enabled or not in parallel using routines. And this process is like heavily concurrent.

uh enables us to employ all the cores of your machine to uh show you menu much faster, and to not wait for it. So, if you could easily spot a difference if you open the ID a year ago and an ID now, you can easily see see how much faster menus became, uh. What else, uh, you could probably face this problem before if you, uh, do a lot of changes outside of ID, for instance git pool, or maybe build, or maybe something else, some some huge change not inside the ID window, and then switch to ID, uh, you could face such file system synchronization, uh, dialog, which is blocking, which is not, it doesn't allow you to use ID before it processes all the files, and it is also because of this, because Intelli ID uses single read write log, and it, uh, have to maintain some guarantees of consistency, and, uh, it have to use, uh, a special virtual file system under the hood, and we now try to fix those. We first of all improved the situation with workspace mod model and improve, uh, like synchronization process.

itself, so it is much faster, and we no longer do a lot of checks. Synchronous checks under the hood, and we also implemented uh prefet, which does this even before you focused ID. Oh, sorry, blow up, uh, yeah. Uh, and now you can expect that once you change something on disk ID, uh, sports this change immediately and tries to, uh, like sync those files without even waiting for you to switch to ID, which improves station and you probably should not face this modal state anymore. Uh, I would like to also highlight briefly importing project improvements. They are important and huge. Um, first of all, uh, grle project import improved a lot. Uh, we introduced many improvements there, uh, and we no longer put ID to dump mode and while waiting for sync. We also improved parallelization in there, and we work closely with Gradle Team, uh, from Gradle Inc to improve paralyze further. Uh, previous year you could also spot many improvements in maving Imports, uh, like it is also now heavily parallel. We optimize generation of sources and

memory consumption. In there, we also posted such a nice picture on Twitter where we checked Maven import for a very well-known Quarkus project itself. You can easily find sources on GitHub also, and where there we had a huge improvement from 61 seconds to 30 seconds for the entire Maven sync for the entire Quarkus project, which is quite big and has hundreds of modules, which is quite an enormous amount. And if we also check our Mega update mixes, we see that we really changed this for our users, and it is much better perceived now. And not only this is in tests like observed in tests, but also users can easily spot this on their own real-life scenarios. Here, finally, I would like to mention ongoing work on K2 compiler in Cortland. Please stay tuned. There are many more changes in Cortland this year. Our team and the team of Cortland compiler work closely on introducing K2 compiler, which is much faster, much more parallel and concurrent, and this would improve situation.

uh perceived performance and Real Performance in ID further for instance. If we check our dashboard for cotland K2, we can easily sport that in like most of cases completion improved uh up to four times. Sometimes like it was 4 seconds before and now it is like 1 second or uh or something like this. In many many scenarios, cotland K2 shows much better uh like performance on highlighting completion, find uses, and many other uh tasks. Uh I would maybe skip the question on jbr 21 uh this time because we have somewhat limited time. But because of our tests and performance improvements, we can now easily spot any performance degradations. And such degradation was caught recently when we tried to use fresh Java 21. We faced with a big degradation in startup time. And because of this, we postpone such activity migration to new Java, but we continue it further uh in this summer release. And we were able to fix this. And this is again a huge thank you to our uh test automation team who does great job on maintaining our performance tests.

observing any uh degradations. I would also mention some tools that we use. We heavily use our own profiler based on a sync profiler, uh named intelligent profiler, for CPU memory locations and hip dumps. Sometimes we use your for many other tasks, such as CL loing analysis, and we sometimes use gvmt agents to uh profile and spot some differences in tests, and uh finally I would like to mention how you can help us, your users. Please don't hesitate to post issues on UT. All the performance-related issues like are red, we uh check them all, we open all snapshots that you attach, we check all thread dumps that you attach, and we try to read and understand every performance degradation you have. So please don't hesitate. We have a special uh page on our support, uh website how to report such performance problems to us, and where you can learn how to do this in a more productive manner, and finally I would like to uh say huge thank you to all the department, all the intell idea, uh Team, all the product teams for a lot.

of performance improvements last year. Without you, my dear colleagues, it would not be possible. And all the improvements done by many different teams and different people. I would like to say huge thank you again. And let's see how it goes further. We have a lot of plans for the next stages in here. Mal, I guess it is everything from my side. If we have some time for questions, we can cover a couple. If not, we can do this. First of all, thank you so much. It was a lot to cover in one session, so kudos to you. Um, so we don't have a lot of time, just a minute. So I'll quickly U take just a couple of one or two questions. So I asked how people, uh, how for how long people have been using intelligent idea. So there were a lot of exam answers since for two years, since ever it has been around. So a lot of answers on that one. So one question that I have time to take is um.

so you talked about um switching off the downloading in gradal projects. So there was one question, how can we turn it back on automat. There is a such option in advancing settings first of all. And also there is a huge button in gradal tool window to do it once and for all. So for sure we have special Puggles and switches. You can uh get it back easily. But from our usage data, we certainly know that really people do not use that for Maven a lot. Like not not not a lot of folks usually care about this. But if you care, you can you can switch it on and and use it further for sure. And this is one question that I wanted to take uh. The simple reason was a lot of times developers think that some issue could be related to the performance of the IDE. But it might not be so uh. This issue could be related to something that the user is doing. Or it could be IDE. So how do they make the distinction and how do they navigate this problem similar problems yeah.

usually, if you check our reporting performance problem uh page, you can easily spot that we ask you to hit some actions in ID to collect some CPUs shots and data, which exactly shows if it is related to ID itself or not because CP snsh shots, they easily show that makes sense, and with that, thank you so much Yuri. That was an amazing s. Daniel was answering all the questions, amazing answers, so thank you so much again for your time, and we'll see you soon. Yeah, thank you Mala, see you, bye. [Music] bye.

How IntelliJ IDEA Performance Improved: Past, Present, and Future

The official channel for the Leading Java and Kotlin IDE.
Subscribe to receive demos, tutorials and new features highlightings.


How IntelliJ IDEA Performance Improved: Past, Present, and Future

How IntelliJ IDEA Performance Improved: Past, Present, and Future

Scripts