Ticket #4405 (new defect)

Opened 2 years ago

Last modified 2 years ago

Some types of files "View" damn slow in modern Ubuntu/MC

Reported by: lokapal Owned by:
Priority: major Milestone: Future Releases
Component: mcview Version: master
Keywords: Cc:
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description

Hello, developers!

I cannot precisely what happened exactly and when, but Ubuntu 16.04 with standard MC:
GNU Midnight Commander 4.8.15
Built with GLib 2.47.3
Using the S-Lang library with terminfo database
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
With internationalization support
With multiple codepages support
Virtual File Systems: cpiofs, tarfs, sfs, extfs, ext2undelfs, ftpfs, sftpfs, fish
Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;

time file rep1_I.bam
rep1_I.bam: gzip compressed data, extra field

real 0m0,001s
user 0m0,001s
sys 0m0,000s

can open for "View/F3" BAM files in time much lesser that second. Even 10G-12G files (that is now too uncommon for these filetypes).
Relatively modern and stable already Ubuntu 20.04 opens for "View/F3" 714M BAM file in 13 seconds at pretty modern hardware (and we can wait for eternity to "View" at 12G file)!

MC:GNU Midnight Commander 4.8.28
Built with GLib 2.64.6
Built with S-Lang 2.3.2 with terminfo database
Built with libssh2 1.8.0
With builtin Editor and Aspell support
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
With internationalization support
With multiple codepages support
With ext2fs attributes support
Virtual File Systems:

cpiofs, tarfs, sfs, extfs, ext2undelfs, ftpfs, sftpfs, fish

Data types:

char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;

time file rep1_I.bam
rep1_I.bam: Blocked GNU Zip Format (BGZF; gzip compatible), block length 577

real 0m0,004s
user 0m0,004s
sys 0m0,000s

It's obvious for me that some script now tries to process the whole file before I can view it. I cannot find any manual concerning VIEWER behaviour for file extensions and/or file types. Why previous MC opens the same files in the old OS many times faster? Why "file" is at least 4 times slower at MUCH modern hardware (new OS: Ryzen 5950X, old OS: Xeon E5-2697 v2). How can I fix it?

Change History

comment:1 Changed 2 years ago by lokapal

Workaround created:

Add to mc.ext from the very beginning:

regex/\.(bam|BAM)$
       Open=
       View=%view{ascii} samtools head %f

to eliminate this problem. Samtools http://www.htslib.org/ has to be installed.
I suggest that the same problem will be with the CRAM file format (and the same solution applies).

Anyway it would be cool to have possibility to exclude some files by names/extensions from any autodetections and have manual/examples how to do it.
Probably, default behaviour should be changed (do not try to autodetect file format at all), or option should be added to the appropriate part of interface/menus.

Version 0, edited 2 years ago by lokapal (next)
Note: See TracTickets for help on using tickets.