Announcement

Collapse
No announcement yet.

Faster Rendering Of Our Hundreds Of Thousands Of Benchmark Results

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Faster Rendering Of Our Hundreds Of Thousands Of Benchmark Results

    Phoronix: Faster Rendering Of Our Hundreds Of Thousands Of Benchmark Results

    If visiting LinuxBenchmarking.com to view the daily performance benchmark tracker results on the Linux kernel, GCC, LLVM Clang, or Mesa and opting to view the results for a very long duration, you may have noticed some results were slow to appear or the page would time-out before hand. I've now landed some improvements into the Phoronix Test Suite's rendering code that should dramatically speed-up the process...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Are you ever going to take advantage of any javascript frameworks for dynamically assembling graphs? It would probably reduce your server load by a lot.

    Comment


    • #3
      +1 for above. Moreover, wouldn't it be a way to solve a lot of screen size related problems?

      Michael, I was wondering... Your last benchmark was about filesystems. While I understand these automated benchmarks are here mostly for keeping track of regressions, are they using different filesystems? (that's the case, IIRC). This would forbid direct comparison of some benchmark results, such as SQLite, wouldn't it?

      Comment


      • #4
        Originally posted by dsx724 View Post
        Are you ever going to take advantage of any javascript frameworks for dynamically assembling graphs? It would probably reduce your server load by a lot.
        No plans to... The actual graphing part of the process is very minimal. Much heavier is all of the XML parsing, merging of result files, and other data-related processes. The pts_Graph code is already quite efficient.

        But beyond that no real plans to utilize any JS frameworks due to also needing to render PNG/GD images for older browsers not handling SVG and also PTS supports generating PDFs and as part of that relies on pts_Graph for embedding graphs into the PDF files. There's also a few other reasons that make using a JS framework for graphs not a good fit.

        Originally posted by M@yeulC View Post
        +1 for above. Moreover, wouldn't it be a way to solve a lot of screen size related problems?

        Michael, I was wondering... Your last benchmark was about filesystems. While I understand these automated benchmarks are here mostly for keeping track of regressions, are they using different filesystems? (that's the case, IIRC). This would forbid direct comparison of some benchmark results, such as SQLite, wouldn't it?
        What screen related issues? Any issues can solve quite easily with SVG.

        Yes some of the trackers are using different file-systems. These graphs aren't meant for comparing performance between systems but rather looking at each system's performance over time.
        Michael Larabel
        https://www.michaellarabel.com/

        Comment


        • #5
          Originally posted by Michael View Post

          No plans to... The actual graphing part of the process is very minimal. Much heavier is all of the XML parsing, merging of result files, and other data-related processes. The pts_Graph code is already quite efficient.
          Do you really need XML? I wonder if you would get any speed-up switching to JSON, even if you didn't I'm sure it would end up in nicer looking code.

          Comment


          • #6
            Originally posted by tarceri View Post
            Do you really need XML? I wonder if you would get any speed-up switching to JSON, even if you didn't I'm sure it would end up in nicer looking code.
            I've done some tests and a JSON'ified version of results and test profile over XML really wouldn't yield a huge speed improvement... So at end of day for now just easier maintaining existing compatibility until either having a lot of extra time on my hand to change it over or coming up with some customer demand for needing it in JSON.
            Michael Larabel
            https://www.michaellarabel.com/

            Comment

            Working...
            X