Taming The Dinosaur: How Eclipse was Performance Tuned
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Thoms, Karsten
While increasing amount of features usually result in poorer performance and more memory consumption, Eclipse Photon has proven the opposite: The Eclipse Platform got faster and less memory hungry than before. This has been achieved by intensive profiling of multiple use cases and refactorings derived from the analysis. This talk will take a look behind the scenes and shows how profiling tools can help to understand performance bottlenecks in Eclipse based products and Java applications in general. Attendees will learn about the YourKit Java Profiler tool, which while being a commercial product can be used for free on Open Source development. I will discuss some former hot spots identified in the Eclipse platform with analysis screenshots and how they got resolved.
 Yeah, welcome. I would like to show you a little bit about the backgrounds in performance tuning in the Eclipse platform and give you an insight on that. Shortly introduced myself, I'm Carsten, working for Itamis, a company in Germany, and my main duty is working on a framework called Eclipse X-text, that's for creating programming languages, and we heavily use Eclipse. I do it every day. And when I work with huge projects, X-text is one of the largest projects at Eclipse. I hate to do wait for my IDE. So the thing is, what can we do to speed it up again? What I actually do is, when I see something which is not as fast as I imagine, I immediately start a profiler and look what's actually happening behind the scenes. Actually using a profiler is a good idea unless you're a guy like that. The performance tuning is a little bit the hunt of the iceberg. So what you see is actually always the surface. And only if you cut off the surface, another peak comes up, and then you see different things. To tune code, you have to cut off everything what you see, and then the next thing comes up, and then you work on that. So it's quite a recursive action. Performance matters in many ways. First of all, there's a difference between tuning the performance in means of speed of the environment, but also in means of memory consumption. So these are often diverse to each other. When I want to improve the speed, I usually need more memory and vice versa. It is important that the start of Eclipse is fast. The UI must be snappy. Good processes are also long-running, for example, if you install software on Eclipse, this is long-running task, and so there are many places to improve. And I would like to show you some examples of how we did this and where. For example, we recognize that if you have a large search result, 5,000 matches of string, you can expand that tree. Left side was Eclipse Oxygen, right side is Eclipse Photon, and you expand that on the same time. You see, okay, that's pretty fast now, and this is still blinking and waiting. Yeah, it's ugly. But what was happening behind the scenes, this tree here got refreshed all the time, and which each child that was expanded, it got refreshed again. And also the cursor came back and switched between the busy mode and the idle mode. Once you see that, it's quite easy to fix. It's actually very few, okay, you can't really read it, but the old code was just saying, okay, do expand everything. The new code just turned off refreshing, then do the expand, and when the tree was expanded, you can refresh again the UI. So you just wait until the computation has happened, and then you just display it once and not with each node. Project is also something which bothers me. Huge amount of projects in my workspace. And actually, the project is a single thread. It's running on different threads, but it's running sequentially for each project, and each project has a set of project builders, like a Java builder, a schema builder, and whatever builders, and they run sequentially for each project. So what we are working now on is to enable parallelization of that. There's a new option which allows you to set, I want to build multiple projects at once, but this means that this works only when the builders configured on that project allow this also, and this is ongoing work at the moment. The Java builder has now the option that it can participate in such a process, but when you have a second builder which is not enabled in such a relaxed rule, then it will block again the workspace, and it will again run sequentially. But this is now what we improve. One builder after each other, that they allow locking of partial trees of the workspace. And when this is done, and you have unrelated projects in your workspace, the Eclipse built framework recognizes, okay, I can build these projects in parallel, and these must be sequential because I have a project relationship between them. When you work on macOS, there has also been something improved in the event dispatching. The code in the SWT implementation of macOS was whenever there was an event in the UI, and there are many events in the UI, like mouse move, clicking, keyboard entering, whatever. It decided through a long, if else, cascade, what did you actually do? And in the 20th switch, it would maybe decide, okay, I moved the mouse. So you did 19 operations that did not make sense. So this was reflected to switch case. So now it could be decided on branch table what is actually the event that you did. The effect is, we have, that's actually a screenshot from a profiler called Yorket that I'm heavily using. The effect is that here we saw that in the display class, the processing, this is within the dispatching, took 13 seconds while measuring. The measuring case is actually 100,000 lines Java code, scrolling that down. So you have plenty of events running in the UI. And within new change, we could cut off almost one second of UI processing. And UI processing happens in just one single thread. So whatever you can save on the UI thread, this makes the UI more responsive. So it's, okay, it's just 5%er, but it's 5% more performance on UI at all. Let's take another example. We have Git project. We want to import projects. Can't really see what's written there, but I'm not selecting the Git project. Say import projects. And now I see a dialogue and you see here that it shows me very fast, which files and folders are now scanned. It looks fast, but isn't. Let's do it nowadays. And actually, I did not see really anything. What's behind that? The thing is, when the directory is scanned, it shows each and every single file on the UI thread. So it makes a synchronous call to the UI thread for each file and folder. But actually, you're only interested in knowing, okay, there's something happening, it's processing roughly that directory. We introduced a new API, which is called the Fruttler, which you can now use. The idea is that you can suppress some messages. You can say, okay, it's not necessary to read more than one message per 100 milliseconds, for example. So every message between is received, but swallowed. And then by introducing, using that Fruttler, and to say, okay, use the update label function just only 100 milliseconds, that's fast enough for the human eye. So you can report as many information as possible to the Provis monitor, but you get only updates on the UI every 100 milliseconds. And so the UI is not slowed down. One hotspot that we identified is also during a complete build is that the string replace all function popped up in one use case. It's always dependent on the use case. This won't happen in many different other scenarios. But in this use case, it was a full project build of a huge workspace. Shared up that the replace all function costs six seconds of time. Okay, that's quite much on the machine that can compute an endless loop in four seconds. And actually what the suspicious method was here, process name in API tooling doesn't matter, but actually this is one of the hotspots that we showed up. And the problematic code was this here. So here you see replace all slash by dot looks quite normal. What's the problem here? Exactly, this is here using a regular expression. Actually you can just replace that by the replace method and say, okay, replace character by character. But some unskilled programmer just use replace all because the intention was to replace all slash by dots. But it's not fast. And yeah, after that, the method got down here, string replace in this example to three milliseconds from six seconds to three milliseconds. Check for updates. If you use that function to search for new updates of plugins installed to Eclipse. It showed up that here we had hotspot in the XML writer. So write in XML during that process cost two minutes. Of course there's much happening there, the registries in Eclipse are XML based and when you do updates and they are processed and edited and so on. Of course you do many XML stuff there. But two minutes during an update process, only for writing XML seems a lot of time. What was the problem here? You can't really hear it's using an XML writer and print out characters or strings. Problem was only it was unbuffered. So just simply writing this, wrapping this into a buffered writer, remove that completely. But again, you need to have a use case where you see, okay, that might be a problem. You have a profile, look at what is happening and then you will find that. By reading the code you won't find this. Again another use case was that, you are scrolling down the 100,000 lines of Java code. We saw that many SWT errors were raised during that. And they actually cost some time. It's not much, again just a second. But looking into that was that, yeah, there was a function called that tried to get an offset of a character at a specific point. And yeah, this method can return, throw an exception when there is no character at this place. This is totally expected. So it was just swallowed this exception. And the problem just is, if you do this very frequently and use exceptions as return types, then the construction of exceptions is costly. Because you have to create a new object and fill in the stack trace. And if you make this very often, then this costs time. We introduced just a new method in the API method which does the same but returns a negative value in the case that there's no return value. Effect was, for this case, before the change there were 10,000 illegal argument exceptions thrown. And we now saved 1.6 seconds processing time just by changing that. So small changes make an effect. Talking about memory a little bit, if you start up Eclipse, then you would recognize that it consumes not so much memory anymore. We are really tweaking that. For example, in JDT we are tweaking the zero length arrays. When you do not have annotations, for example, or whatever, then often the case is that you create a new array with zero length. And this wastes memory. We infected this by using constants. So that you have a single constant and say, if you want to have an empty array, just use the constant. And so you can effect all that. This is one change where we did this. For example, the code was, children is new Java element with children size. Maybe you should check first, is the children collection empty? And if it's empty, then just use no elements constant. So this is happening in Java tooling very frequently. And so you can waste, you are wasting memory otherwise. And here we have another place where annotations in Java code. Each method can have annotations and each parameter can have an annotation and so on. But often you don't have any annotations. So the same case here again, it was half a megabyte of waste. Sounds much, but sounds few, but we are already micro tuning this. Java doc was another place and so on. You can also optimize data structures to use. In this example, this is from P2. There's a class which is called the audit properties. It basically holds a map of properties. And often this map is either empty or just has one element. And by default, this data structure just uses a hash map. But a hash map is huge. For the case that you don't have any element, we now initialize this map lazily. So it's zero when you do not have any properties. And if you have just a single value, then a single map is now used from the collections framework. And only if you add a second property to this object, then it will use a hash map. So in many, many, many cases, you can use less memory for these maps. It showed up here that the retained size of the object of that kind used six megabytes in this example of memory and 6.2 and after optimization 4.6. So again, 1.5 megabytes of memory saved. Remember there was something in JET found. We have here something which is called the class path access rule. There were two million objects of that held and they used 200 megabytes of heap space. The class path access rule is an information which is available for each package, for each project, in each jar that you have in the workspace. I have a huge workspace. So this showed up in that amount. But when looking into that, one can see that actually you don't need so many instances because many instances are equal. So what we did now is analyze that and you see it's really wasting many times. 200 duplicates that are wasting 100 kilobytes of memory than the next duplication, 199. And so many, many, many, this multiplies really much. But with introducing a weak cache, we could reduce the same thing to 3,000 instances from 2 million and using 300 kilobytes instead of 200 megabytes of memory. So we saved 200 megabytes by using this cache. But it erased a bug in Eclipse. Strangely due to the introduction of this cache, Eclipse started to erase a full build on startup, totally somehow unrelated. But you could not know that this was causing that bug. And unfortunately, we actually delivered this with Eclipse Photon. But fortunately, it was discovered then. And with the new release cycle of Eclipse, now every three months, we could provide a fix in Eclipse 2018-09. So now we have both the working birds and also less memory consumption. So what I want to show you here is this is my development workspace for Eclipse platform. It's building around one gigabyte of feed. So we have to make this into a relation. This old-gen space is around 600 megabytes. And we use Eden space between 100 and 400 megabytes for that building, that workspace. So it's totally sufficient with one gigabyte of feed. These are 40 Git repositories. All projects from these Git repositories. Let's count them. Let's count how many projects are in this workspace. And 1,600 projects are in this workspace. Let's count Java files. And yeah, around about 60,000 Java files that are in this workspace. And the IDE is happy with one gigabyte of feed. It's almost nothing. Compare that to your Slack client. But we still have problems. The slope scrolling on macOS is one of the longest running performance problems. And we still not have a solution really for that. Actually some of these things that I showed you with the illegal argument exceptions that are thrown. And so these came from examination of that problem. On macOS, it's so that the scrolling of files doesn't feel nice. We're still searching for that. That's one of the most common bugs on Eclipse. I think we are roughly at a common number, 360 or so. And many attempts to change that. But we're still struggling with that. We also identified maybe hotspots in SWT where we can maybe improve something. There's a class called text-width. And it tries to compute the width of tabs. And often it's the same. So maybe it's a candidate for caching. But we still do not know if it's valid to cache it here. And we hope to improve that in the future. Also if you make a text search with very fast results, then you can experience blocking of threads. So this is the red bars show that threads are waiting on each other. And you see sometimes they do. It's not actually not really a deadlock. But close to it. Actually, we're working on UI freezes. So you know this typical spinning wheel of death. And this always happens when heavy computations are done in the UI thread. And what we try to do is to put the computations in the background, in background threads, and come back to the UI thread only to do the display thing. And what you see here is a screenshot of an application called the error reporting system. Maybe if you use Eclipse use, so that pop up, here something happened, do you want to report this? And also for UI freezes, we get reports to that and the Eclipse developers can now see, OK, where did we have UI freezes? And then we can focus on that places. But still ongoing. Problem that we have is at Eclipse, we are strongly API compatible. So API never changes. And this makes it sometimes hard to really provide fixes. And we can't really make use of all the fancy stuff that Java provides us with for concurrency. Because the API was not designed that way. And we can just say, OK, we changed the API. Because there are plenty of tools outside that really depend on the stability of the API. For this native thing, the scoring issue, we are lacking deep knowledge about Kakoa. We are good Java programmers, but there's not much knowledge about the internals of the Mac implementation. So yeah, that's one of the problems. Last thing that I want to show is something that I'm currently working on. The use case is again the software update. So if you issue that search for updates, then you will see, OK, it contacts all the update locations that you configured. And yeah, it finds that, OK, if you have a location which is actually a composite of locations, and then it finds again it's a composite. And this is all happening sequentially. And you easily end up with hundreds of update locations that you process sequentially. And the idea is now, why can't this be parallelized? And in a prototype, this is now the new prototype. On the left side, I see the debug perspective. And I will now issue the software update. And now I see that many threats are doing things. What I'm actually doing right now is just to say, OK, when I have a composite, which contains certain amounts of children, then issue a job in the background for each of the children. And then synchronize again when the work is done. And this must just be now polished a little bit. We need a preference for that in Eclipse UI so that you can say how many threats are allowed to query the network at once. Because there are limitations depending on infrastructure. Some companies don't allow to process 20 network connections at once or so. And so we need to throttle this. And with some luck, we get this into the next Eclipse IDE. But if not, then for sure with the version after that. We are already now in milestone two release. And it's not much time until milestone three is issued. And then we can't change anything for next release. And then it has to go in the release after. Yep, I have to stop. So thank you. You saw many things can help. And every change that we do there in the Eclipse platform helps millions of users every day. I think I don't have free time for questions now. The next speaker can already show up. But if you have questions, I can answer them outside.
 Yeah, welcome.  I would like to show you a little bit about the backgrounds in performance tuning in the  Eclipse platform and give you an insight on that.  Shortly introduced myself, I'm Carsten, working for Itamis, a company in Germany, and my main  duty is working on a framework called Eclipse X-text, that's for creating programming languages,  and we heavily use Eclipse.  I do it every day.  And when I work with huge projects, X-text is one of the largest projects at Eclipse.  I hate to do wait for my IDE.  So the thing is, what can we do to speed it up again?  What I actually do is, when I see something which is not as fast as I imagine, I immediately  start a profiler and look what's actually happening behind the scenes.  Actually using a profiler is a good idea unless you're a guy like that.  The performance tuning is a little bit the hunt of the iceberg.  So what you see is actually always the surface.  And only if you cut off the surface, another peak comes up, and then you see different  things.  To tune code, you have to cut off everything what you see, and then the next thing comes  up, and then you work on that.  So it's quite a recursive action.  Performance matters in many ways.  First of all, there's a difference between tuning the performance in means of speed  of the environment, but also in means of memory consumption.  So these are often diverse to each other.  When I want to improve the speed, I usually need more memory and vice versa.  It is important that the start of Eclipse is fast.  The UI must be snappy.  Good processes are also long-running, for example, if you install software on Eclipse,  this is long-running task, and so there are many places to improve.  And I would like to show you some examples of how we did this and where.  For example, we recognize that if you have a large search result, 5,000 matches of string,  you can expand that tree.  Left side was Eclipse Oxygen, right side is Eclipse Photon, and you expand that on the  same time.  You see, okay, that's pretty fast now, and this is still blinking and waiting.  Yeah, it's ugly.  But what was happening behind the scenes, this tree here got refreshed all the time,  and which each child that was expanded, it got refreshed again.  And also the cursor came back and switched between the busy mode and the idle mode.  Once you see that, it's quite easy to fix.  It's actually very few, okay, you can't really read it, but the old code was just saying,  okay, do expand everything.  The new code just turned off refreshing, then do the expand, and when the tree was expanded,  you can refresh again the UI.  So you just wait until the computation has happened, and then you just display it once  and not with each node.  Project is also something which bothers me.  Huge amount of projects in my workspace.  And actually, the project is a single thread.  It's running on different threads, but it's running sequentially for each project, and  each project has a set of project builders, like a Java builder, a schema builder, and  whatever builders, and they run sequentially for each project.  So what we are working now on is to enable parallelization of that.  There's a new option which allows you to set, I want to build multiple projects at once,  but this means that this works only when the builders configured on that project allow  this also, and this is ongoing work at the moment.  The Java builder has now the option that it can participate in such a process, but when  you have a second builder which is not enabled in such a relaxed rule, then it will block  again the workspace, and it will again run sequentially.  But this is now what we improve.  One builder after each other, that they allow locking of partial trees of the workspace.  And when this is done, and you have unrelated projects in your workspace, the Eclipse built  framework recognizes, okay, I can build these projects in parallel, and these must be sequential  because I have a project relationship between them.  When you work on macOS, there has also been something improved in the event dispatching.  The code in the SWT implementation of macOS was whenever there was an event in the UI,  and there are many events in the UI, like mouse move, clicking, keyboard entering, whatever.  It decided through a long, if else, cascade, what did you actually do?  And in the 20th switch, it would maybe decide, okay, I moved the mouse.  So you did 19 operations that did not make sense.  So this was reflected to switch case.  So now it could be decided on branch table what is actually the event that you did.  The effect is, we have, that's actually a screenshot from a profiler called Yorket that  I'm heavily using.  The effect is that here we saw that in the display class, the processing, this is within  the dispatching, took 13 seconds while measuring.  The measuring case is actually 100,000 lines Java code, scrolling that down.  So you have plenty of events running in the UI.  And within new change, we could cut off almost one second of UI processing.  And UI processing happens in just one single thread.  So whatever you can save on the UI thread, this makes the UI more responsive.  So it's, okay, it's just 5%er, but it's 5% more performance on UI at all.  Let's take another example.  We have Git project.  We want to import projects.  Can't really see what's written there, but I'm not selecting the Git project.  Say import projects.  And now I see a dialogue and you see here that it shows me very fast, which files and  folders are now scanned.  It looks fast, but isn't.  Let's do it nowadays.  And actually, I did not see really anything.  What's behind that?  The thing is, when the directory is scanned, it shows each and every single file on the  UI thread.  So it makes a synchronous call to the UI thread for each file and folder.  But actually, you're only interested in knowing, okay, there's something happening, it's processing  roughly that directory.  We introduced a new API, which is called the Fruttler, which you can now use.  The idea is that you can suppress some messages.  You can say, okay, it's not necessary to read more than one message per 100 milliseconds,  for example.  So every message between is received, but swallowed.  And then by introducing, using that Fruttler, and to say, okay, use the update label function  just only 100 milliseconds, that's fast enough for the human eye.  So you can report as many information as possible to the Provis monitor, but you get only updates  on the UI every 100 milliseconds.  And so the UI is not slowed down.  One hotspot that we identified is also during a complete build is that the string replace  all function popped up in one use case.  It's always dependent on the use case.  This won't happen in many different other scenarios.  But in this use case, it was a full project build of a huge workspace.  Shared up that the replace all function costs six seconds of time.  Okay, that's quite much on the machine that can compute an endless loop in four seconds.  And actually what the suspicious method was here, process name in API tooling doesn't  matter, but actually this is one of the hotspots that we showed up.  And the problematic code was this here.  So here you see replace all slash by dot looks quite normal.  What's the problem here?  Exactly, this is here using a regular expression.  Actually you can just replace that by the replace method and say, okay, replace character  by character.  But some unskilled programmer just use replace all because the intention was to replace all  slash by dots.  But it's not fast.  And yeah, after that, the method got down here, string replace in this example to three  milliseconds from six seconds to three milliseconds.  Check for updates.  If you use that function to search for new updates of plugins installed to Eclipse.  It showed up that here we had hotspot in the XML writer.  So write in XML during that process cost two minutes.  Of course there's much happening there, the registries in Eclipse are XML based and when  you do updates and they are processed and edited and so on.  Of course you do many XML stuff there.  But two minutes during an update process, only for writing XML seems a lot of time.  What was the problem here?  You can't really hear it's using an XML writer and print out characters or strings.  Problem was only it was unbuffered.  So just simply writing this, wrapping this into a buffered writer, remove that completely.  But again, you need to have a use case where you see, okay, that might be a problem.  You have a profile, look at what is happening and then you will find that.  By reading the code you won't find this.  Again another use case was that, you are scrolling down the 100,000 lines of Java code.  We saw that many SWT errors were raised during that.  And they actually cost some time.  It's not much, again just a second.  But looking into that was that, yeah, there was a function called that tried to get an  offset of a character at a specific point.  And yeah, this method can return, throw an exception when there is no character at this  place.  This is totally expected.  So it was just swallowed this exception.  And the problem just is, if you do this very frequently and use exceptions as return types,  then the construction of exceptions is costly.  Because you have to create a new object and fill in the stack trace.  And if you make this very often, then this costs time.  We introduced just a new method in the API method which does the same but returns a negative  value in the case that there's no return value.  Effect was, for this case, before the change there were 10,000 illegal argument exceptions  thrown.  And we now saved 1.6 seconds processing time just by changing that.  So small changes make an effect.  Talking about memory a little bit, if you start up Eclipse, then you would recognize  that it consumes not so much memory anymore.  We are really tweaking that.  For example, in JDT we are tweaking the zero length arrays.  When you do not have annotations, for example, or whatever, then often the case is that you  create a new array with zero length.  And this wastes memory.  We infected this by using constants.  So that you have a single constant and say, if you want to have an empty array, just use  the constant.  And so you can effect all that.  This is one change where we did this.  For example, the code was, children is new Java element with children size.  Maybe you should check first, is the children collection empty?  And if it's empty, then just use no elements constant.  So this is happening in Java tooling very frequently.  And so you can waste, you are wasting memory otherwise.  And here we have another place where annotations in Java code.  Each method can have annotations and each parameter can have an annotation and so on.  But often you don't have any annotations.  So the same case here again, it was half a megabyte of waste.  Sounds much, but sounds few, but we are already micro tuning this.  Java doc was another place and so on.  You can also optimize data structures to use.  In this example, this is from P2.  There's a class which is called the audit properties.  It basically holds a map of properties.  And often this map is either empty or just has one element.  And by default, this data structure just uses a hash map.  But a hash map is huge.  For the case that you don't have any element, we now initialize this map lazily.  So it's zero when you do not have any properties.  And if you have just a single value, then a single map is now used from the collections  framework.  And only if you add a second property to this object, then it will use a hash map.  So in many, many, many cases, you can use less memory for these maps.  It showed up here that the retained size of the object of that kind used six megabytes  in this example of memory and 6.2 and after optimization 4.6.  So again, 1.5 megabytes of memory saved.  Remember there was something in JET found.  We have here something which is called the class path access rule.  There were two million objects of that held and they used 200 megabytes of heap space.  The class path access rule is an information which is available for each package, for each  project, in each jar that you have in the workspace.  I have a huge workspace.  So this showed up in that amount.  But when looking into that, one can see that actually you don't need so many instances  because many instances are equal.  So what we did now is analyze that and you see it's really wasting many times.  200 duplicates that are wasting 100 kilobytes of memory than the next duplication, 199.  And so many, many, many, this multiplies really much.  But with introducing a weak cache, we could reduce the same thing to 3,000 instances from  2 million and using 300 kilobytes instead of 200 megabytes of memory.  So we saved 200 megabytes by using this cache.  But it erased a bug in Eclipse.  Strangely due to the introduction of this cache, Eclipse started to erase a full build  on startup, totally somehow unrelated.  But you could not know that this was causing that bug.  And unfortunately, we actually delivered this with Eclipse Photon.  But fortunately, it was discovered then.  And with the new release cycle of Eclipse, now every three months, we could provide a  fix in Eclipse 2018-09.  So now we have both the working birds and also less memory consumption.  So what I want to show you here is this is my development workspace for Eclipse platform.  It's building around one gigabyte of feed.  So we have to make this into a relation.  This old-gen space is around 600 megabytes.  And we use Eden space between 100 and 400 megabytes for that building, that workspace.  So it's totally sufficient with one gigabyte of feed.  These are 40 Git repositories.  All projects from these Git repositories.  Let's count them.  Let's count how many projects are in this workspace.  And 1,600 projects are in this workspace.  Let's count Java files.  And yeah, around about 60,000 Java files that are in this workspace.  And the IDE is happy with one gigabyte of feed.  It's almost nothing.  Compare that to your Slack client.  But we still have problems.  The slope scrolling on macOS is one of the longest running performance problems.  And we still not have a solution really for that.  Actually some of these things that I showed you with the illegal argument exceptions that  are thrown.  And so these came from examination of that problem.  On macOS, it's so that the scrolling of files doesn't feel nice.  We're still searching for that.  That's one of the most common bugs on Eclipse.  I think we are roughly at a common number, 360 or so.  And many attempts to change that.  But we're still struggling with that.  We also identified maybe hotspots in SWT where we can maybe improve something.  There's a class called text-width.  And it tries to compute the width of tabs.  And often it's the same.  So maybe it's a candidate for caching.  But we still do not know if it's valid to cache it here.  And we hope to improve that in the future.  Also if you make a text search with very fast results, then you can experience blocking  of threads.  So this is the red bars show that threads are waiting on each other.  And you see sometimes they do.  It's not actually not really a deadlock.  But close to it.  Actually, we're working on UI freezes.  So you know this typical spinning wheel of death.  And this always happens when heavy computations are done in the UI thread.  And what we try to do is to put the computations in the background, in background threads,  and come back to the UI thread only to do the display thing.  And what you see here is a screenshot of an application called the error reporting system.  Maybe if you use Eclipse use, so that pop up, here something happened, do you want to report  this?  And also for UI freezes, we get reports to that and the Eclipse developers can now see,  OK, where did we have UI freezes?  And then we can focus on that places.  But still ongoing.  Problem that we have is at Eclipse, we are strongly API compatible.  So API never changes.  And this makes it sometimes hard to really provide fixes.  And we can't really make use of all the fancy stuff that Java provides us with for concurrency.  Because the API was not designed that way.  And we can just say, OK, we changed the API.  Because there are plenty of tools outside that really depend on the stability of the  API.  For this native thing, the scoring issue, we are lacking deep knowledge about Kakoa.  We are good Java programmers, but there's not much knowledge about the internals of  the Mac implementation.  So yeah, that's one of the problems.  Last thing that I want to show is something that I'm currently working on.  The use case is again the software update.  So if you issue that search for updates, then you will see, OK, it contacts all the update  locations that you configured.  And yeah, it finds that, OK, if you have a location which is actually a composite of  locations, and then it finds again it's a composite.  And this is all happening sequentially.  And you easily end up with hundreds of update locations that you process sequentially.  And the idea is now, why can't this be parallelized?  And in a prototype, this is now the new prototype.  On the left side, I see the debug perspective.  And I will now issue the software update.  And now I see that many threats are doing things.  What I'm actually doing right now is just to say, OK, when I have a composite, which  contains certain amounts of children, then issue a job in the background for each of  the children.  And then synchronize again when the work is done.  And this must just be now polished a little bit.  We need a preference for that in Eclipse UI so that you can say how many threats are  allowed to query the network at once.  Because there are limitations depending on infrastructure.  Some companies don't allow to process 20 network connections at once or so.  And so we need to throttle this.  And with some luck, we get this into the next Eclipse IDE.  But if not, then for sure with the version after that.  We are already now in milestone two release.  And it's not much time until milestone three is issued.  And then we can't change anything for next release.  And then it has to go in the release after.  Yep, I have to stop.  So thank you.  You saw many things can help.  And every change that we do there in the Eclipse platform helps millions of users every day.  I think I don't have free time for questions now.  The next speaker can already show up.  But if you have questions, I can answer them outside.
Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_0_167.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_168_1367.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_1368_1475.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_1476_2123.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_2124_2951.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_2952_4079.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_4080_5519.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_5520_6323.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_6324_7175.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_7176_7715.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_7716_8927.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_8928_8975.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_8976_9119.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_9120_10499.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_10500_11999.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_12000_13799.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_13800_15083.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_15084_15143.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_15144_16571.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_16572_17675.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_17676_18035.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_18036_21059.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_21060_22787.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_22788_23375.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_23376_23471.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_23472_23531.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_23532_23771.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_23772_24695.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_24696_25643.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_25644_26327.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_26328_26447.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_26448_28295.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_28296_29027.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_29028_30923.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_30924_31547.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_31548_31619.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_31620_33215.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_33216_33299.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_33300_33503.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_33504_34103.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_34104_35171.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_35172_35219.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_35220_36623.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_36624_37463.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_37464_38219.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_38220_39851.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_39852_41603.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_41604_41675.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_41676_42959.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_42960_44507.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_44508_45431.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_45432_45575.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_45576_45671.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_45672_45719.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_45720_45767.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_45768_45887.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_45888_46151.png Taming_The_Dinosaur__How_Eclipse_was_Performance_Tuned_7Wyu15u1_Pw_46152_46290.png