Non-geek warning: This is an article about optimizations to the browser engine. It’s possible to read and understand, but it will get pretty technical. It basically says Opera developers have significantly reduced the memory usage when browsing websites, and plan to submit the improvements also to make all Blink-based browsers better.

Two weeks ago we released the beta version of Opera 39, and it is time to mention one of its improvements: heap compaction, an optimization pass for the Blink memory manager. It reduces memory usage by several megabytes per tab when browsing popular websites. Learn more about how we optimized memory usage in Opera.

Background: Memory fragmentation

Many users experience high memory usage, and one reason for that can be memory fragmentation, which happens when memory becomes a random sequence of differently sized chunks of used and unused memory. To put it simply, if you insert plates of different sizes haphazardly into a cupboard, it will be hard to use all the available space. If you stack them orderly, it will be more efficient, but it will also take more time to do so. And, since we put the plates (i.e., memory) in and remove them from the cupboard all the time, we unfortunately can’t spend much time on making it look pretty.

The same thing happens with the memory management.

To solve this, we have added a cleanup phase to the “plate” management inside Blink, which we call heap compaction. It reorders the memory to make use less RAM, make the future memory operations faster … and look pretty, too.

How we optimized memory usage in Opera

We attacked memory fragmentation by implementing a cheap, single-pass inplace compaction of heaps (picture a “heap” as the “cupboard” in the analogy above). The benefits are two-fold: less heap memory is allocated, and live objects are packed tighter, thereby increasing memory locality and speed of access.

How big are the memory savings

We conducted research to discover how heap compaction translates into memory savings. This involved visiting several popular websites, such as Wikipedia and, as well as doing some occasional same-site navigation and interactions with the content. After approximately 15 minutes, we sampled the total heap size for the compactable sub-heaps.

The results show that, with this feature, the Blink heap size decreases significantly. As a very positive example, for Gmail compaction reduces the size from 6.8MB to 2.3MB, which, for many users, will translate into better general laptop performance. Heaps will naturally be compacted again as fragmentation regrows, throughout the lifetime of a site visit.

Heap compaction

Opera’s engineers partner closely with our Google counterparts to reduce the memory use of the rendering engine Blink, and, in upcoming months, we are planning to upstream this technology to the the Blink project, as well.

Download Opera 39 beta and stay tuned for even more memory usage improvements we have in store for you.

The Opera Blink Team

Back to top
  • Zin

    Surely this is one of the best updates i ever saw, congrats on opera/google teams for this nice addition. 🙂

  • nanana1

    Opera goes one up on Blink with its developed heap compaction code in its engine !
    Cool !

  • Matheus Bombonato

    Congrats and thank you for these “under the hood” improvements! Keep with the good work!

    • Daniel Bratell

      Thank you! I am always a bit afraid that these more technical and internal improvements will sound boring if talked about but I and the other people working on the browser engine love tinkering and making it just a little bit better.

  • Trevor Gough

    Is this in Opera 40 (the current Developer version), also ?

    • Nekomajin43

      “Opera’s engineers partner closely with our Google counterparts to reduce the memory use of the rendering engine Blink, and, in *upcoming months*, we are planning to upstream this technology to the the Blink project, as well.”

      • NoName

        That does not really answer their question. Opera Dev is not the same repository as Blink.

        • Nekomajin43

          But it uses Blink.

          • Trevor Gough

            Doesn’t Opera Beta use Blink too, though?

          • We do, but we have an internal repository of Blink with our own patches on.

            We’re continuously updating from upstream Blink. In other words, yes we use Blink, but we also have Opera specific changes to it. We’re contributing back to Blink and Chromium continuously. But some patches makes no sense to upstream, some patches Google don’t want, some patches are not ready to be upstreamed yet, etc etc.

            The reason for this is that it’s simpler for us to first fix the problems we see in Opera, then after they’ve been proven effective, we can contribute them back to upstream. 🙂

          • M92

            Does it work in both x32 and x64 dev versions or only on x32?

        • Daniel Bratell

          It is a fair question since we recently released one or two things in beta first and then after a short delay in dev. Heap compaction though is available in all recent builds so this is not an exception to the normal code flow.

          • NoName

            Yea, the original question is fair.
            I was responding to Nekomajin43 🙂

    • Daniel Bratell

      Yes, we have been testing this for a while in public releases. We got a lot of feedback from people using Opera 38 Developer and Beta which helped us finish it, and we are very thankful for that help!

      We could have talked about this earlier but we have been a bit busy talking about other things so I had to wait until the others took vacation. 🙂 (Joking, partially 😉 )

  • NoName

    I like these kind blog posts.

    – What is the speed of each pass?
    – When and how often does it run?
    – Did you plan this ahead with the Blink team, or did you make it on your own and hope they will pull the changes?
    – Does this potentially help against heap overflows?

    • Daniel Bratell

      So the information can be even more technical you say? 🙂 I had to synchronize the details with other people so I didn’t get this wrong. Because it’s embarrassing to be wrong on the Internet.

      Any additional compaction of the heap will be done when Blink performs an idle-time garbage collection(GC). The heap compaction’s design and scope fits within the time budget allotted to such GCs.

      The policy is quite simple for now: perform compaction during the next idle GC when a measure of fragmentation has been exceeded and some time after any previous compaction.

      Great topic — the problem of heap overflow is real and (far too) common, but I think that would be claiming too much 🙂 The heap compaction here keeps some of the Blink engine’s heap regions in a tidy and minimal state without itinerant slop and garbage, but there are other bigger consumers of memory. But having long-running tabs behave better with respect to memory usage and resources, is something we (Opera) do care about and have focused on here.

      • NoName

        Thanks for your answer.

        I don’t mind that you don’t write all the technical details in the blog post. As long as you answer people in the comments like this, I’m happy 🙂

        Blink (and Webkit) has “always” been very bad at long running tabs. It’s nice to see you looking at this.
        I’m also interested in what the Oilpan project can do longterm (new/better memory diagnostic tools for the Blink developers etc.).

      • SQL

        So you’re compacting the Oilpan heap – i suppose you got sof to do that considering his general involvement with the project? :p

        I suppose you don’t want to touch the V8 heap all that much, and they have their own cool (long term) projects for reducing memory.

        Hopefully the project-trim folks will identify more memory duplication that can be fixed like they did with encoded images being duplicated in Skia and PartitionAlloc.

      • Vux777

        nice job on optimizing memory fragmentation

        I think much bigger (and more visible to end users) impact on memory savings would be bringing back tab hibernation that Opera had previously (behind a flag)

    • Daniel Bratell

      Oh, and remember that we are also the Blink team.

      We have access to two different code trees though so it is possible for us to land things (first) in the Opera version of Blink, and if we want to try something out, something that is a bit more complicated, that is what we have to do. Or if it is something where we prioritize differently than other large contributors to Blink.

      • NoName

        Yea, sorry. Meant to say the Google Blink team 🙂
        Those that decide what’s getting pulled. Or do you all have a say in that? It is really a true democracy? 😀

  • Юлия

    Is this available in the 64 bit Opera Dev as well?

    • Nekomajin43

      “Opera’s engineers partner closely with our Google counterparts to reduce the memory use of the rendering engine Blink, and, in *upcoming months*, we are planning to upstream this technology to the the Blink project, as well.”

      • Юлия

        Well that doesn’t really answer my question. Since it’s lower down the stream in the Beta x86, one could assume that it’s in Dev x86 as well. But whether it’s been implemented for the x64 version it’s still unknown. There are differences between them and also Opera seems to prioritise the 32 bit version, which makes things less certain.

        (I did read the entire blog post, certain paragraphs twice, before I asked my question.)

        • Daniel Bratell

          Opera for Mac is 64 bit and maybe so is Opera for Linux so we don’t really do any changes that can’t work for 32 or 64 bit unless it depends on the operating system.

          There are ups and downs with both 32 bit and 64 bit on Windows but I better leave that discussion to people actually working on the 64 bit version for Windows.

        • Nekomajin43

          My bad, sorry.

    • Daniel Bratell

      Same features in both versions (except for a few things that can be done with 64 bit and not with 32 bit like using more memory. 🙂 ).

  • Dark Magician

    If data is true, excellent work. As far as I understood this will roll in 39 Stable?
    Or you will test it until it goes into Blink officially?

    • Daniel Bratell

      We have been testing this in Opera since Opera 38 beta and it seems to work really well so I am pretty confident it will be included in every upcoming Opera release regardless of when we have it fully included in default Blink.

  • x a

    Off topic: Could one of the distinguished moderators here do something regarding the fact, that virtually any of my recent comments are being classified as spam (and never un-flagged)‽

  • Junaid Ahmed

    Excellent work! After using facebook for sometimes, Opera sometimes occupied all the available memory and becomes laggy. CPU usage also increased(from 8% to 30%?) significantly. Hope this’ll decrease the problem.
    Share? You can keep it to yourselves if you like. Google does many optimizations in the engine while implementing in Chrome, they don’t share them. The raw engine is open source for their own benefit.

    • Daniel Bratell

      Ah, interesting to know if it will.

      It might, but that depends on what causes the problems you see. There are certain problems this will help against, and certain problems it will not help against (like memory needed for large images, though there are Blink improvements coming there as well).

      • David_Gould

        If you scroll down Facebook, I don’t think Opera does/did any memory compaction until you ran out of memory.

        All the photos and Javascript are incredibly memory intensive and can easily take 1 GB per tab.

        Given the importance of FB to many internet users, it would be worth having a look at…

      • David_Gould

        What I’m finding is that Opera is happy to leave the system with zero memory free.

        So simply opening a new tab can cause 5s of swapping.

  • Wando Schneider

    @danielbratell:disqus Continue to share with us the “boring” stuff. 🙂

    • Ricardo J. Barberis

      Yes, please! This is the right kind of “boring” 🙂

    • Damian eDameXxX Stępnik

      It’s a gold! I really enjoy reading this kind of stuff.

  • This will have benefits to millions :yes:

    I am guessing some of the sites picked are from feedback and from testing, I know some sites the memory used depends on the layout and the layout depends on the window size (resizing the window and the page changes part of the layout (Facebook does this))

  • Oskar

    This is the most exciting feature in a long time! Awesome! Keep up the good work!

  • I always felt like there was this *something* going on which dramatically increased memory usage more than it should. People have for the longest time cried of memory leaks. Leaks have been found in some browsers, fixed, but the excessive usage has largely remained.

    I could sum the expected use of all tabs and it just kept piling up during the sessions. I’m happy to finally learn of the problem, because with something like up to 100-300% better use of the memory it’s clear that this was *the* major underlying factor to me. And it’s fixed. Big day.

    One question though: Extensions are known to bump up usage too. Will these also be affected? Maybe they will be affected especially so, often being pretty much pure Javascript?

    • Daniel Bratell

      Yes, I am also not happy with the current situation and neither, but I’m afraid “something” is “many things” (one being that crazy web developers, no offense – it can be fun to go crazy from time to time, try to make their sites as cool as possible without checking resource usage).

      This is one battle won and we can celebrate a little, but then we want to keep improving memory usage even more.

      The one upcoming improvement I know of right now is related to images but I’m not sure when that will be done. It looks promising though!

    • NoName

      Javascript is overall going to see memory improvements when crankshaft i dropped in V8.
      But I have no idea how much it affects the js from extensions, since the memory improvement is something that could be shared across all tabs.

      • Daniel Bratell

        I’m *very* positive to the Ignite project (which will allow Crankshaft and Full CodeGen to be dropped). It looks like it can cut 10-30% of average script memory which is huge. It seems that there is a bit to go though since TurboFan couldn’t fully replace Crankshaft without a (small) performance hit last I checked.

        (I might be a bit biased because the general architecture will end up being similar to what we used in Presto. 🙂 )

        • NoName

          Hah, nice 😀

  • Iandol

    Daniel, I know you’ve been tinkering for ages with memory (checking your upstream commits to blink). We do really enjoy these more technical articles, and it is “important” to see how Opera engineers are contributing back. Would love to see more of these articles!

  • Damian eDameXxX Stępnik

    I’m curious how this affect on RAM usage while listen web version of Spotify at because I had often problem with that page.

    Hey Opera, we need more benchmarks 🙂

  • Michael A. Puls II

    Awesome! Thanks for the post Daniel.

  • Vlad Violenty

    This technologies work in O40 Developer?

  • CrashNBurn71

    Will such close collaboration with the Chrome Team continue when the sale of Opera (excluding Media Works & Opera TV) is finalized?

    • NoName

      It would not make any sense to stop that, as long as they want to develop the Opera browsers.

  • Well, its pretty hard for me to handle this. But for sure, i will try it later. Im happy to see that article. Thanks a lot

  • Paranam Kid

    I am on Opera Developer 40, and the memory leak is huuuuuuuge: after a few hours open it stand at more than 2.5 Gig. Why is heap compaction not implemented in the Developer version? I would have thought the Dev version is ahead of all the other versions, NOT behind.

    • Vux777

      Why is heap compaction not implemented in the Developer version?

      according to this, it is implemented

      • Paranam Kid

        If it is, it is NOT working at all, as my earlier post shows. Makes one wonder how effective heap compaction really is.

        • Daniel Bratell

          Heap compaction is just one of the things that need to change to make the browser smaller. There is ongoing work with better image management for instance. With current web pages, there might be an insane amount of images concurrently used so it’s important to be as efficient as possible.

          It is hard to say why your browser uses so much memory. The most common cause is large web pages or many tabs but browser bugs is also possible.

          If you open the builtin task manager (Shift+Esc) and sort on “Private Memory”, you might see if some particular site is using all memory.

  • thank you my favorite web site

  • Peter Buyze

    I am on Opera Dev 40.0.2306.0, and within 2 hours Opera’s memory footprint has swollen from 220 Mb to 1.7 Gb. This is totaly unacceptable. I switched to OD because of the VPN & battery saver, and would like to continue using OD, but right now every couple of hours I have to close & relaunch OD.
    Conclusion: as far as I know there is no on/off toggle for heap compaction, so HC does not seem to be working. Am I missing something or is HC not even implemented yet in my version of OD???

    • Daniel Bratell

      Heap Compaction is available and used in your version, but it’s but part of the puzzle. It will help significantly with some sites, and very little with other sites (graphic heavy sites for instance).

      It is always hard to deduce why a particular browser is using a lot of memory and the Chromium project has been working this last year on tools to make it easier, but it’s still not easy enough.

      For you, since the most common cause is a misbehaving web page, I would take a look in the builtin task manager (Shift+Esc) and sort on “Private Memory”. Maybe there is a site at the top that is causing most of your problems. Otherwise I can only suggest to keep updating as we keep improving things. Sorry to not have any more exact suggestion.

      • Paranam Kid

        Thanks for your reply.
        I don’t really care if Heap Compaction per se is working or not, I just don’t want Opera’s memory footprint to get out of control, which is what is happening.

        It is not related to a particular web page or site. Invariably, whatever is open, Opera balloons to 2.5 – 3 Gb within 2 hours.

        So the memory issue is definitely not under control. But, like you suggest, I will just keep updating & keep my fingers crossed that eventually it will be fixed.

  • Tom

    Actually Opera is leaking quite much memory (linux version). This morning I started with three open tabs and around 100mb ram usage. 8 hours later opera consumes 5gb(!!!!) ram with only three tabs opened. Restarting opera and we are back at 100mb. Memory of closed tabs should be freed completely (and returned to the OS)

  • Marguerite

    Wow. Opera was fine until version 41.0. It was using up ALL my memory(literally). I ran a virus and malware scan and everything was fine. I tried to uninstall it and couldn’t so I had to download it from the site again and then uninstall. Used to be one of my go to browsers but never again. I’ll be sticking to Chrome and Firefox.

  • Artık Bahis Siteleri‘ne Kredi kartınız ile ödeme yapmanıza gerek kalmamıştır. Artık ön ödemelerinizde Paykasa Kart kullanarak kendinizi güven altına almanız mümkündür. Kesinlikle dolandırılmadan ve gönül rahatlığında ödeme yapma imkanından yararlanmanız mümkündür.

  • Antonio_X75

    Opera 42 for OSX is consuming 2+ gb of RAM with no tabs opened. This is astonishingly ridiculous. A web browser consuming far more RAM than a professional audio software with tons plugins.

    • irelevant

      Only 2+ GB of ram? My opera consumes 4 GB of ram and since im a gamer 4GB of my 6GB (5,45) makes my games pretty F…. unplayable not to count that when Sh.t hits the fan my pc freezes because of not having available ram to operate with I cant even close opera, because it freezes and even if I do close it I still have to kill it from task manager, because it still uses like 2M bytes of memory there even though its closed

      • Daniel Bratell

        Have you looked at the built-in task manager (Menu -> Enable Developer Menu, Menu -> Developer Tools -> Task Manager, or just shift+esc). It might give you an idea of what tab/process uses all the memory, and even if it doesn’t help you, it might give us an idea what is happening on your computer.

  • Beast MC

    I have opera V46 and still eating 8Gb RAM just like the other Shitty browsers : Chrome, FireFox … I don’t understund why this is huge ?

    • Michael

      Extensions? Or opening alot of tabs it could be a virus installed an extension(s) I’ve had that happen to family members

  • sanper
  • palutz

    Opera 48 is simply useless and sometimes even freeze my old (not so old) notebook with only 8Gb of RAM (Linux!!!). This is even worse than Chrome and FF (combined!!!).
    WTH happened?? It was so good.

    PS: NO extensions installed (before started with the usual, useless, question about).

  • csmanowar


  • Need to lower memory usage in V48. Washpost web pages start about 400 MB and reach 2GB within a few days with their javascript per tab. That’s true for the original home grown forum and the new Coral Project software. I’m sure all the ads and other crud doesn’t help. With a couple tabs open my laptop is out of memory.

  • Leonardo Armando Iarrusso

    opera 48 – takes too much memory. I have 8gb of ram and it continues to get ram.
    With 9 tabs with normal sites and 1 tab with video (that is not in hd) I get full usage of ram and the video sometimes have audio glitches.
    No extensions are in use.

  • My website does not appear on the opera. Can people who have this kind of problem give information