@Leency - this looks good.... But I wonder how much hit to performance this structure has? Before the key (file type) was the first field per row.
From some quick testing, this change only saves ~15 bytes of the compressed .ini... but adds extra decoding overhead that may negate that small saving? I also think we should prefer code simplicity.
Test method
KPACK compression was approximated with xz: xz --format=lzma --check=none --lzma1=mode=normal,dict=64KiB,nice=273,lc=3,lp=0,pb=2 -k -c icons.ini > icons.ini.lzma
Results:
icons.ini 2,035 B > icon2ext.ini 1,380 B (saves 655 bytes)
Compressed:
icons.ini 821 B > icon2ext.ini 806 B (saves 15 bytes)
@Leency - this looks good.... But I wonder how much hit to performance this structure has? Before the key (file type) was the first field per row.
From some quick testing, this change only saves ~15 bytes of the compressed `.ini`... but adds extra decoding overhead that may negate that small saving? I also think we should prefer code simplicity.
<details>
<summary>Test method</summary>
KPACK compression was approximated with xz: `xz --format=lzma --check=none --lzma1=mode=normal,dict=64KiB,nice=273,lc=3,lp=0,pb=2 -k -c icons.ini > icons.ini.lzma`
**Results:**
icons.ini 2,035 B > icon2ext.ini 1,380 B (saves 655 bytes)
Compressed:
icons.ini 821 B > icon2ext.ini 806 B (saves 15 bytes)
</details>
@Leency - this looks good.... But I wonder how much hit to performance this structure has? Before the key (file type) was the first field per row.
From some quick testing, this change only saves ~15 bytes of the compressed .ini... but adds extra decoding overhead that may negate that small saving? I also think we should prefer code simplicity.
Test method
KPACK compression was approximated with xz: xz --format=lzma --check=none --lzma1=mode=normal,dict=64KiB,nice=273,lc=3,lp=0,pb=2 -k -c icons.ini > icons.ini.lzma
Results:
icons.ini 2,035 B > icon2ext.ini 1,380 B (saves 655 bytes)
Compressed:
icons.ini 821 B > icon2ext.ini 806 B (saves 15 bytes)
Actually we do not compress ini files, but maybe should?
So now calculation is between uncompressed icons.ini and uncompressed icon2ext.ini.
But the main reason of change is readability.
> @Leency - this looks good.... But I wonder how much hit to performance this structure has? Before the key (file type) was the first field per row.
>
> From some quick testing, this change only saves ~15 bytes of the compressed `.ini`... but adds extra decoding overhead that may negate that small saving? I also think we should prefer code simplicity.
>
> <details>
>
> <summary>Test method</summary>
>
> KPACK compression was approximated with xz: `xz --format=lzma --check=none --lzma1=mode=normal,dict=64KiB,nice=273,lc=3,lp=0,pb=2 -k -c icons.ini > icons.ini.lzma`
>
> **Results:**
> icons.ini 2,035 B > icon2ext.ini 1,380 B (saves 655 bytes)
> Compressed:
> icons.ini 821 B > icon2ext.ini 806 B (saves 15 bytes)
>
> </details>
Actually we do not compress ini files, but maybe should?
So now calculation is between uncompressed icons.ini and uncompressed icon2ext.ini.
But the main reason of change is readability.
Ok @Leency - thanks for your consideration. Is it possible to benchmark the overhead on memory or cpu to decode the ini? Or it's minimal?
@Burer - Just a note on git / merging... this will lose the change history for the icons.ini file. In the past, developers have requested file history to be preserved. We can first merge a PR that simply changes the file name, without edits, so git tracks the rename and file history is preserved. Then this PR can be merged with the edits to the file.
Ok @Leency - thanks for your consideration. Is it possible to benchmark the overhead on memory or cpu to decode the ini? Or it's minimal?
@Burer - Just a note on git / merging... this _will_ lose the change [history](https://git.kolibrios.org/KolibriOS/kolibrios/commits/branch/main/data/common/File%20Managers/icons.ini) for the `icons.ini` file. In the past, developers have requested file history to be preserved. We can first merge a PR that simply changes the file name, without edits, so git tracks the rename and file history is preserved. Then this PR can be merged with the edits to the file.
This icon file is used only in the eolite file manager (also known as kfm2) and the opendialog service. The changes are not critical for other programs to work.
This icon file is used only in the eolite file manager (also known as kfm2) and the opendialog service. The changes are not critical for other programs to work.
Doczom
approved these changes 2026-07-07 10:02:23 +00:00
Doczom
requested review from Burer 2026-07-07 10:02:59 +00:00
Doczom
requested review from dunkaist 2026-07-07 10:03:00 +00:00
Doczom
requested review from Sweetbread 2026-07-07 10:03:00 +00:00
dunkaist
approved these changes 2026-07-11 18:47:12 +00:00
bad_Dr3dd0x
approved these changes 2026-07-12 03:39:35 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Doczom
Burer
Sweetbread
dunkaist
bad_Dr3dd0x
Before:
Now:
Fixes #226
icons.ini => icon2ext.inito data/icons.ini: transform format to icon2ext.ini (fix #226)@Leency - this looks good.... But I wonder how much hit to performance this structure has? Before the key (file type) was the first field per row.
From some quick testing, this change only saves ~15 bytes of the compressed
.ini... but adds extra decoding overhead that may negate that small saving? I also think we should prefer code simplicity.Test method
KPACK compression was approximated with xz:
xz --format=lzma --check=none --lzma1=mode=normal,dict=64KiB,nice=273,lc=3,lp=0,pb=2 -k -c icons.ini > icons.ini.lzmaResults:
icons.ini 2,035 B > icon2ext.ini 1,380 B (saves 655 bytes)
Compressed:
icons.ini 821 B > icon2ext.ini 806 B (saves 15 bytes)
Actually we do not compress ini files, but maybe should?
So now calculation is between uncompressed icons.ini and uncompressed icon2ext.ini.
But the main reason of change is readability.
Ok @Leency - thanks for your consideration. Is it possible to benchmark the overhead on memory or cpu to decode the ini? Or it's minimal?
@Burer - Just a note on git / merging... this will lose the change history for the
icons.inifile. In the past, developers have requested file history to be preserved. We can first merge a PR that simply changes the file name, without edits, so git tracks the rename and file history is preserved. Then this PR can be merged with the edits to the file.I don't think there is any performance decrease..
This icon file is used only in the eolite file manager (also known as kfm2) and the opendialog service. The changes are not critical for other programs to work.
2b24d174bcto8ad630a1fb