-
Notifications
You must be signed in to change notification settings - Fork 177
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SVG] Main performance issue #369
Comments
I'm not entirely sure why the difference is so high. Is it because you are running Emacs under WSL? If not, can you provide me with a profiler report? |
Jimmy Yuen Ho Wong ***@***.***> writes:
I'm not entirely sure why the difference is so high.
My guess is that there is too much properties to compute at each turn of
the loop and there is a lot of candidates. In previous version (master)
there is not so much properties to compute.
If you want to try all-the-icons on Helm with both versions (svg and
master) you can checkin the Helm svg branch, it is working with both
branches of all-the-icons, icons are enabled in helm-find-files with
helm-ff-icon-mode, in helm-buffers-list with helm-buffers-show-icons and
in helm-imenu with helm-imenu-use-icon (yo can hide types with
helm-imenu-hide-item-type-name).
It is easy to see the difference of speed with both branches of all-the-icons
with M-x helm-imenu-in-all-buffers.
Also on helm-find-files I can see a slowdow on large directories.
Is it because you are running Emacs under WSL?
My OS is LinuxMint, don't know what is WSL.
…
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.*Message ID: ***@***.***>
--
Thierry
|
Thierry Volpiatto ***@***.***> writes:
Jimmy Yuen Ho Wong ***@***.***> writes:
> I'm not entirely sure why the difference is so high.
My guess is that there is too much properties to compute at each turn of
the loop and there is a lot of candidates.
More exactly, my understanding is that #(" " ... display (... :data)) takes much longer
because Emacs have to setup the image according to (huge) raw data every time
an icon is displayed.
…--
Thierry
|
So no, this is not the reason, it is the repeated calls to locate-library which make things so slow, with this change, I get almost the same performances as before: diff --git a/all-the-icons.el b/all-the-icons.el
index 671037e3b..7f78fd268 100644
--- a/all-the-icons.el
+++ b/all-the-icons.el
@@ -1100,6 +1100,7 @@ Return the icon file name if found."
(fn (all-the-icons--data-name (car mapping))))
(assoc-default (cadr mapping) (funcall fn))))))
+(defvar all-the-icons-svg-library "/home/thierry/elisp/all-the-icons.el/svg/")
(cl-defmacro all-the-icons-define-icon (name alist &key svg-path-finder (svg-doc-processor ''identity) (padding 0))
"Macro to generate functions for inserting icons for icon set NAME.
@@ -1125,7 +1126,7 @@ PADDING is the number of pixels to be applied to the SVG image."
(defun ,(all-the-icons--function-name name) (icon-name &rest args)
(let* ((file-name (all-the-icons--resolve-icon-file-name icon-name ,alist (quote ,name))) ;; remap icons
(size (window-default-font-height))
- (lib-dir (concat (file-name-directory (locate-library "all-the-icons")) ,(format "svg/%s/" name)))
+ (lib-dir (concat all-the-icons-svg-library ,(format "%s/" name)))
(image-path (concat lib-dir ,(or (and svg-path-finder
`(apply ,svg-path-finder file-name lib-dir size args))
'(format "%s.svg" file-name)))) This is of course a dirty patch just to show where the slowdown happens. |
So probably computing the path of the svg directory one time for all is the way to go. |
So even if avoiding locate-library make things much faster, I still see some slowdowns due to stuff being computed at each of the function calls, probably these could be avoided or at least cached (memoized)? |
@thierryvolpiatto see if eb32540 works better. About cache, the icons are cached at here. Caching them at the icon set level is going to blow up memory usage tremendously, and introduce more cache invalidation issues I have to deal with in addition to #367 and #368. Let me know if you can think of other ways to speed up this branch :) |
Jimmy Yuen Ho Wong ***@***.***> writes:
1. ( ) text/plain (*) text/html
@thierryvolpiatto see if eb32540 works better.
Yes, it is the same patch I used yesterday except defvar vs defconst,
around 30s faster on M-x helm-imenu-in-all-buffers!
However it is still not as fast as with master branch, we still have a
lot of work done at each icon computation.
About cache, the icons are cached at here. Caching them at the icon
set level is going to blow up memory usage tremendously, and introduce
more cache invalidation issues I have to deal with in addition to #367
and #368.
I see. I was thinking more of the usage of this:
(apply ,svg-path-finder file-name lib-dir size args)
and this: all-the-icons--normalize-svg-doc
…
Let me know if you can think of other ways to speed up this branch :)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.*Message ID: ***@***.***>
--
Thierry
|
Jimmy Yuen Ho Wong ***@***.***> writes:
Let me know if you can think of other ways to speed up this branch :)
I am now caching helm-imenu icons, it working very well, M-x
helm-imenu-in-all-buffers is now instant :-)
… —
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.*Message ID: ***@***.***>
--
Thierry
|
Jimmy Yuen Ho Wong ***@***.***> writes:
About cache, the icons are cached at here.
Yes but this cover only:
(all-the-icons-cache #'all-the-icons-icon-for-dir)
(all-the-icons-cache #'all-the-icons-icon-for-dir-with-chevron)
(all-the-icons-cache #'all-the-icons-icon-for-file)
(all-the-icons-cache #'all-the-icons-icon-for-mode)
(all-the-icons-cache #'all-the-icons-icon-for-weather)
Caching them at the icon set level is going to blow up memory usage
tremendously, and introduce more cache invalidation issues I have to
deal with in addition to #367 and #368.
Yes, but why caching them all, why not caching them on demand?
E.g. Say I have a list of files:
foo.diff
bar.diff
baz.diff
And I want to append an icon to each file, all the files have the same
type so on foo.diff I use (all-the-icons-octicons "file-diff"), then if
this is cached next call on bar.diff will reuse the previous result.
Actually we have:
(defun all-the-icons-octicons (...)
(compute-icon))
We would have instead
(defun all-the-icons-octicons (...)
(if cached (use-it) (compute-icon)))
Probably only the result of (function name) would be cached and the
&rest args e.g. 'face ... would still be computed.
…
Let me know if you can think of other ways to speed up this branch :)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.*Message ID: ***@***.***>
--
Thierry
|
Jimmy Yuen Ho Wong ***@***.***> writes:
@thierryvolpiatto see if eb32540 works better.
About cache, the icons are cached at here. Caching them at the icon set level is going to blow up memory usage tremendously, and introduce more cache invalidation issues I have to deal
with in addition to #367 and #368.
After digging into this I realize that the caching you provide by
transforming fns with `all-the-icons-cache` makes entries in the hash
table with keys composed of the whole call of function with args (fname
etc...) and comparison is done with 'equal.
That's mean that each filename have its own icon composition in the
cache!
When providing icons in a huge directory containing files of the same
type (e.g. backup dir) your cache is quickly full filled.
Now on Helm I have modified this to cache icon for file by extension,
type or default so that next file reuse the cached version of the
precedent (if it's the same kind of file). This limit the usage of
memory, the cache is never cleared and BTW it is much faster.
…
Let me know if you can think of other ways to speed up this branch :)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.*Message ID: ***@***.***>
--
Thierry
|
For reference: |
Now helm is working fine with this branch, by using caching where needed I have reduced memory usage and increased speed. |
Don't know, whenever I have some time and brain space :) Feel free to send over a PR if you'd like |
Jimmy Yuen Ho Wong ***@***.***> writes:
Don't know, whenever I have some time and brain space :)
Ok, looking forward for it :-).
Feel free to send over a PR if you'd like
We have first to agreed on the issues there is to fix.
Here is one (related to this performance issue):
The wrapper fn `all-the-icons-cache` used to cache icons is taking too
much memory and make BTW the functions transformed by it slow unless
increasing (a lot, by X4 here) `all-the-icons--cache-limit`.
My suggestion (it is what I use in Helm) is to use the type, the file
extension, a mode or a default if none found as key for the cache.
This prevent increasing cache size dramatically.
For this using a global var as cache and letting each function adding to
cache seems the right thing to do IMHO.
… —
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.*Message ID: ***@***.***>
--
Thierry
|
Hello, following up from reddit (helm05).
I made all the changes to make Helm working with this all-the-icons branch.
![Capture d’écran_2023-06-19_07-49-23](https://private-user-images.githubusercontent.com/1533939/246737006-8b39416e-877a-4bcf-b1ff-cd3f4211da2f.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjU5OTMzNTYsIm5iZiI6MTcyNTk5MzA1NiwicGF0aCI6Ii8xNTMzOTM5LzI0NjczNzAwNi04YjM5NDE2ZS04NzdhLTRiY2YtYjFmZi1jZDNmNDIxMWRhMmYucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDkxMCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA5MTBUMTgzMDU2WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9YWMzYTk1NzI3NjdiZmVlMTMzZTM0MGJjNmZlYjU4ZmQ1NzVlYTEwYTkwMTFiZDZmODcxNzYyZGNhZGYyODliMSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.Nof8NsDG1zqanlW_4DnU8WGgAHsbBr-NbMizxDFQc8c)
The main issue I see is a loss of performance because the all-the-icons* functions return now a space with an svg image as display property.
Here from an helm-imenu function:
Now printing the helm-imenu for all buffers (around 100) takes more than 30s whereas with master branch it is nearly instant.
The text was updated successfully, but these errors were encountered: