[BUG] Slow read performance for multichannel EXRs in oiiotool

Đang mở
  • Có gì không ổn?
#4,707 5 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
cpp
Lĩnh vực
performance

Hướng nghiên cứu

Tái hiện sự cố với EXR được cung cấp và oiiotool -v -i:ch=R,G,B,A input.exr -o output.png, sau đó so sánh thời gian với các lần chạy kiểm thử được liên kết. Điều tra đường dẫn đọc EXR đa kênh và ảnh hưởng của việc lọc kênh; được xem là hoàn tất khi quá trình chuyển đổi chỉ sang RGBA không còn có thời gian đọc quá mức như đã báo cáo và các thời gian liên quan được ghi lại.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

performance

Describe the bug

I'm getting very slow read performance on multi-channel EXRs where I just need to parse the RGBA channel and write out a .png file from it.

From 19s on my own machine (which is crazy for a 55 MB exr?) to 5s on the fastest machine I have around.
On my own slow machine, taking the same EXR (on no cold/hot cache) through Fusion to a PNG takes 1.3s

The 19 seconds (but 1.3s through fusion) is on:

  • Windows 10
  • 2x Intel(R) Xeon(R) CPU E5-2680 0 @2.70Ghz
    • Dual Xeon in HP workstation
  • 128 GB RAM
  • 4 GB GPU

The 5 seconds is on:

  • Windows 11
  • AMD Ryzen 9 9900X 12-Core Processor (4.40 Ghz)
  • 128 GB RAM
  • 12 GB GPU

OpenImageIO version and dependencies

See test runs here.

OIIO 3.1.1.0dev | unknown arch?
    Build compiler: MSVS 1943 | C++17/199711
    HW features enabled at build: sse2
    No CUDA support (disabled / unavailable at build time)
Dependencies: DCMTK NONE, expat 2.6.3, FFmpeg NONE, fmt 10.2.1, Freetype 2.13.2, GIF NONE, Imath 3.2.0, JPEG 80,
    JXL NONE, libdeflate 1.23, Libheif NONE, libjpeg-turbo 3.0.4, LibRaw NONE, libuhdr 1.2.0, minizip-ng 4.0.7,
    OpenColorIO 2.4.1, OpenCV NONE, OpenEXR 3.4.0, OpenJPEG NONE, OpenVDB NONE, PNG 1.6.47, Ptex NONE, Ptex NONE,
    pystring 1.1.4, Robinmap 1.4.0, TBB 2022.2.0, TIFF 4.6.0, WebP 1.4.0, yaml-cpp 0.8.0, ZLIB 1.3.1, ZLIB 1.3.1

To Reproduce

Steps to reproduce the behavior:

  1. oiiotool -v -i:ch=R,G,B,A input.exr -o output.png

I'm explicitly filtering -i:ch=R,G,B,A to avoid reading the rest of the file. Also adding :now=1 doesn't make much of a difference.
Other options, like also passing -ch flag are included in the linked test runs with their timings. Using i:ch=... gave the fastest results, but still at 19s seems awful.

Here's the file I'm testing with: https://we.tl/t-Fjm4XVFw8z
It'll only remain available for about four weeks.

Evidence

See test runs here.

Additional Context

This also came up on ASWF slack with a lengthy thread here

Some notable comments from there:

Build options didn't make much of a difference?

So, I've been testing some build variants.
When enabling more hardware features like SSSE3, SSE4.1 SSE4.2, AVX etc. makes it so that the executable doesn't work on my machine - likely due to some AVX (it does work on newer machines but there was no real measurable performance difference on this simple read/write test cases) so I opted going back to just the sse2 default but adding OpenTBB which does run. I've added the performance on my slow machine to the gist (see link below)
There is no noticable speed difference. It remains around 18/19 seconds on my machine

For what it's worth, using --frames 1001-1006 and --parallel-frames also takes about 20 seconds on my machine (so almost no time increase).
Using --frames 1001-1030 with --parallel-frames takes about 53 seconds on my machine.

So I can get good gains with allowing it to read many files. However, it's still the majority the read performance taking a long time it seems.

Ngôn ngữ chính
C++
Star
2.4k
Fork
716
Merge trung bình
2 ngày 8 giờ
Pull request đã merge (30 ngày)
85

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của AcademySoftwareFoundation/OpenImageIO

Tất cả issue của AcademySoftwareFoundation/OpenImageIO

Issue tương tự

Thêm issue về C++

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.