i tried to compute the total for range creation for clojure.core and the numbers i'm seeing are 130ms to 140ms -- that's totaling up the difference between times right before creating a range and right after creation.
my initial measurements suggest that just traversing the tree (no range creation and thus no coloring either) takes 200ms or so.
may be i should try using the query api to see if there is any difference in taversal speed.
i'm not sure if i'm doing this stuff right though (collecting (.getTime (js/Date.))
) -- will try to go over this stuff more again later.
I fail at finding the thread to profile.
i found this but haven't digested it yet: https://www.nicoespeon.com/en/2019/11/fix-vscode-extension-performance-issue/
btw, the machine i'm testing on is one of these: https://www.msi.com/Content-creation/Prestige-15-A10X/Specification
may be your cpu is this? https://ark.intel.com/content/www/us/en/ark/products/191045/intel-core-i7-9750h-processor-12m-cache-up-to-4-50-ghz.html
if so, the base frequency is nicer
as well as some other things π
it looks like the profiler agrees that making ranges takes around 130 ms here
i got this info by adapting the steps from the article posted earlier
Cool!!!
Can you somehow see if making ranges for large files is somehow more expensive than in βnormalβ files?
Maybe it rather is things like doc.positionAt that takes increasingly longer.
i chose clojure's main.clj which is approximately 1/10 in length:
$ ls -al main.clj core.clj
-rw-r--r-- 1 user user 263653 Feb 10 12:18 core.clj
-rw-r--r-- 1 user user 26200 Aug 14 2019 main.clj
the time it took was about 1/10 as wellwdyt?
I think that I need to profile my code a bit closer. π
ha ha ha π well, i hope i'm not screwing things up on this end -- it's entirely possbile!
Very good. Now I measure it in a way that doesn't indicate the increasing cost of Postions and Ranges for larger files.
ok, may be we're both doing it ok then π