* inline @ 2018-10-08 14:16 Emanuel Berg 2018-10-08 17:06 ` inline Eric Abrahamsen 0 siblings, 1 reply; 6+ messages in thread From: Emanuel Berg @ 2018-10-08 14:16 UTC (permalink / raw) To: ding On gnu.emacs.help, there has been a long discussion on inlining functions. Just now, I wrote If you have studied the Gnus source code, you find that the defuns are insanely long. They go on all but forever. This is because Gnus is already slow, and perhaps Elisp is as well, so they don't want to brake it up into modules (smaller defuns) because then it would require the funcall overhead. Perhaps Gnus would benefit from inlining stuff? But be sure to check out the entire thread. There has been lots of changes to the subject line so there are several threads all dealing with the inline stuff. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: inline 2018-10-08 14:16 inline Emanuel Berg @ 2018-10-08 17:06 ` Eric Abrahamsen 2018-10-08 17:22 ` inline Garreau, Alexandre 0 siblings, 1 reply; 6+ messages in thread From: Eric Abrahamsen @ 2018-10-08 17:06 UTC (permalink / raw) To: ding Emanuel Berg <moasen@zoho.com> writes: > On gnu.emacs.help, there has been a long > discussion on inlining functions. > > Just now, I wrote > > If you have studied the Gnus source code, > you find that the defuns are insanely long. > They go on all but forever. This is because > Gnus is already slow, and perhaps Elisp is > as well, so they don't want to brake it up > into modules (smaller defuns) because then > it would require the funcall overhead. > Perhaps Gnus would benefit from > inlining stuff? > > But be sure to check out the entire thread. > There has been lots of changes to the subject > line so there are several threads all dealing > with the inline stuff. FWIW, I think Gnus would gain the most not by inlining more code, but by adjusting its data structures, and introducing more caching at higher levels. So much of the code is simply boilerplate for finding things, or gathering data together, and doing it repeatedly. I think that's where most of the win would be. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: inline 2018-10-08 17:06 ` inline Eric Abrahamsen @ 2018-10-08 17:22 ` Garreau, Alexandre 2018-10-08 18:16 ` inline Eric Abrahamsen 0 siblings, 1 reply; 6+ messages in thread From: Garreau, Alexandre @ 2018-10-08 17:22 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: ding Le 08/10/2018 à 10h06, Eric Abrahamsen a écrit : > Emanuel Berg <moasen@zoho.com> writes: >> On gnu.emacs.help, there has been a long >> discussion on inlining functions. >> >> Just now, I wrote >> >> If you have studied the Gnus source code, you find that the >> defuns are insanely long. They go on all but forever. This is >> because Gnus is already slow, and perhaps Elisp is as well, so >> they don't want to brake it up into modules (smaller defuns) >> because then it would require the funcall overhead. Perhaps Gnus >> would benefit from inlining stuff? >> >> But be sure to check out the entire thread. There has been lots of >> changes to the subject line so there are several threads all dealing >> with the inline stuff. > > FWIW, I think Gnus would gain the most not by inlining more code, but > by adjusting its data structures, and introducing more caching at > higher levels. So much of the code is simply boilerplate for finding > things, or gathering data together, and doing it repeatedly. I think > that's where most of the win would be. So, in the aforementioned discussion, in the end I was right: I/O plays a bigger role there than function call overhead, right? So maybe “breaking the defuns into [parts]”, if done correctly, wouldn’t “make it even slower”? PS: I subscribed just in time to see a first answer to that thread! \o/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: inline 2018-10-08 17:22 ` inline Garreau, Alexandre @ 2018-10-08 18:16 ` Eric Abrahamsen 2018-10-08 19:31 ` inline Adam Sjøgren 0 siblings, 1 reply; 6+ messages in thread From: Eric Abrahamsen @ 2018-10-08 18:16 UTC (permalink / raw) To: ding "Garreau, Alexandre" <galex-713@galex-713.eu> writes: > Le 08/10/2018 à 10h06, Eric Abrahamsen a écrit : >> Emanuel Berg <moasen@zoho.com> writes: >>> On gnu.emacs.help, there has been a long >>> discussion on inlining functions. >>> >>> Just now, I wrote >>> >>> If you have studied the Gnus source code, you find that the >>> defuns are insanely long. They go on all but forever. This is >>> because Gnus is already slow, and perhaps Elisp is as well, so >>> they don't want to brake it up into modules (smaller defuns) >>> because then it would require the funcall overhead. Perhaps Gnus >>> would benefit from inlining stuff? >>> >>> But be sure to check out the entire thread. There has been lots of >>> changes to the subject line so there are several threads all dealing >>> with the inline stuff. >> >> FWIW, I think Gnus would gain the most not by inlining more code, but >> by adjusting its data structures, and introducing more caching at >> higher levels. So much of the code is simply boilerplate for finding >> things, or gathering data together, and doing it repeatedly. I think >> that's where most of the win would be. > > So, in the aforementioned discussion, in the end I was right: I/O plays > a bigger role there than function call overhead, right? Well I think it's hard to separate out that cleanly. (I also haven't sat down and done the profiling, so this is an educated guess.) Updating from servers takes a while, of course, but when people complain about Gnus being slow, I don't think they're complaining about hitting "g" and having to wait a few seconds. I think mostly they're complaining about the time it takes to open and display a summary buffer. That's a combination of I/O time (requesting enough header data from the server to build the summary lines) and producing the lines themselves, which I think often *is* bound by computation time: formatting the lines, maybe calculating scoring, and building threads correctly. Shutting threading off or using a simpler threading algorithm, for instance, gives a noticeable speedup. I don't see what we can do about the server requests (Gnus already has facilities for prefetching). Probably more can be done to pre-render and cache the summary buffers, but Gnus already has quite a few optimizations here (inlined byte-code, for example). > So maybe “breaking the defuns into [parts]”, if done correctly, wouldn’t > “make it even slower”? Like I said, I haven't profiled, but I wouldn't guess this is a main cause of slow-down. Really someone should just sit down with the profiler and try to find the bottlenecks. Eric ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: inline 2018-10-08 18:16 ` inline Eric Abrahamsen @ 2018-10-08 19:31 ` Adam Sjøgren 2018-10-08 20:48 ` inline Emanuel Berg 0 siblings, 1 reply; 6+ messages in thread From: Adam Sjøgren @ 2018-10-08 19:31 UTC (permalink / raw) To: ding Eric writes: > Like I said, I haven't profiled, but I wouldn't guess this is a main > cause of slow-down. Really someone should just sit down with the > profiler and try to find the bottlenecks. Yes! I can't agree enough; profile, measure before, measure after. :-), Adam -- "I pragmatically turn my whims into principles!" Adam Sjøgren asjo@koldfront.dk ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: inline 2018-10-08 19:31 ` inline Adam Sjøgren @ 2018-10-08 20:48 ` Emanuel Berg 0 siblings, 0 replies; 6+ messages in thread From: Emanuel Berg @ 2018-10-08 20:48 UTC (permalink / raw) To: ding Adam Sjøgren wrote: > Yes! I can't agree enough; profile, measure > before, measure after. Do it yourself Adam :) What you can't measure, you can't control. -- Pierre Vernier (Well, he could have said it, at least.) -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-10-08 20:48 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-10-08 14:16 inline Emanuel Berg 2018-10-08 17:06 ` inline Eric Abrahamsen 2018-10-08 17:22 ` inline Garreau, Alexandre 2018-10-08 18:16 ` inline Eric Abrahamsen 2018-10-08 19:31 ` inline Adam Sjøgren 2018-10-08 20:48 ` inline Emanuel Berg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).