[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PERFORMANCE] Why some org code is so deep invoked?
From: |
Christopher M. Miles |
Subject: |
Re: [PERFORMANCE] Why some org code is so deep invoked? |
Date: |
Fri, 12 Aug 2022 22:30:28 +0800 |
User-agent: |
mu4e 1.8.6; emacs 28.1 |
Ihor Radchenko <yantar92@gmail.com> writes:
> "Christopher M. Miles" <numbchild@gmail.com> writes:
>
>>> I do not see much issue with deep nesting of the code.
>>
>> Is this deep nested code normal in Emacs Lisp?
>>
>> Usually (based on my less than 20 times profiling experience), Emacs
>> wouldn't have deeper code than 40 levels. But my attachment profiler
>> report has more than 100 levels.
>>
>> If this is normal and fine, It's OK. I repeat, I ask this question for
>> curious purpose which want to get an answer for not important question.
>
> It depends. You are looking at the complex code here, which is not
> necessarily common.
>
> However, lisp nesting is tangent to performance. Shallow nesting can be
> slow while deep nesting can be fast. Or vice versa.
>
>>> Could you please clarify what exactly is your problem?
>>> Is agenda generation slow?
>>
>> From the profiler report, you can see that Agenda is slow on clock table
>> generation because I have ~org-agenda-start-with-clockreport-mode~
>> enabled. And this deep code invocation is from it too. It's about 5
>> seconds to generate the org-agenda clock table. Actually I can tolerate
>> this time, Just found this performance issue when profiling and curious
>> to ask this question.
>
> Note that your profiler result does not look like taken from a 5
> second-lasting code:
>
> 390 13% - completing-read
>
> Completing read takes >10% *CPU time* of the 5 seconds? Suspicious. I'd
> retry to get the profile.
>
> Also, I suggest to use M-x write-file in the profiler buffer when
> sharing something as deeply nested as you got. The resulting file is
> much more comfortable to view - it will preserve all the actual profiler
> data.
>
> I will refrain from trying to deduce anything from the profiler for now.
>
> Please try to reproduce the report again and share it with us. Then, I
> will try to see if we can do anything on the Org side.
I found previous message attached profiler file does not contains
profiler data (I misunderstand that the buffer write to file through
=M-x write-file= contains expand entry structure info....).
Now I use keyboard macro to expand all entries (I previous expand entry
manually is really hand expensive....). I attach profiler report file again
(v3).
profiler-cpu-report-3.log
Description: Text document
profiler-memory-report-3.log
Description: Text document
--
[ stardiviner ]
I try to make every word tell the meaning that I want to express without
misunderstanding.
Blog: https://stardiviner.github.io/
IRC(libera.chat, freenode): stardiviner, Matrix: stardiviner
GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
signature.asc
Description: PGP signature
- [PERFORMANCE] Why some org code is so deep invoked?, Christopher M. Miles, 2022/08/11
- Re: [PERFORMANCE] Why some org code is so deep invoked?, Ihor Radchenko, 2022/08/11
- Message not available
- Re: [PERFORMANCE] Why some org code is so deep invoked?,
Christopher M. Miles <=
- Message not available
- Re: [PERFORMANCE] Why some org code is so deep invoked?, Ihor Radchenko, 2022/08/13
- Re: [PERFORMANCE] Why some org code is so deep invoked?, Christopher M. Miles, 2022/08/13
- Message not available
- Re: [PERFORMANCE] Why some org code is so deep invoked?, Ihor Radchenko, 2022/08/13
- Re: [PERFORMANCE] Why some org code is so deep invoked?, Christopher M. Miles, 2022/08/13