Re: [scheme-reports-wg2] Threads and futures
Linas Vepstas
(19 Mar 2022 05:54 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Marc Nieper-Wißkirchen
(19 Mar 2022 08:24 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
John Cowan
(19 Mar 2022 18:57 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Linas Vepstas
(19 Mar 2022 20:04 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Marc Nieper-Wißkirchen
(19 Mar 2022 22:11 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Linas Vepstas
(20 Mar 2022 07:50 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
John Cowan
(20 Mar 2022 22:34 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Marc Feeley
(21 Mar 2022 04:49 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Marc Nieper-Wißkirchen
(21 Mar 2022 06:28 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Marc Nieper-Wißkirchen
(21 Mar 2022 06:54 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Ray Dillinger
(21 Mar 2022 19:00 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Dr. Arne Babenhauserheide
(21 Mar 2022 16:54 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Marc Nieper-Wißkirchen
(21 Mar 2022 16:04 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Taylan Kammer
(23 Mar 2022 14:20 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Marc Nieper-Wißkirchen
(23 Mar 2022 14:28 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Dr. Arne Babenhauserheide
(23 Mar 2022 15:40 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Marc Nieper-Wißkirchen
(23 Mar 2022 15:34 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Dr. Arne Babenhauserheide
(23 Mar 2022 22:08 UTC)
|
Re: [scheme-reports-wg2] Threads and futures Ray Dillinger (01 Apr 2022 23:04 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Per Bothner
(01 Apr 2022 23:21 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Ray Dillinger
(01 Apr 2022 23:28 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Per Bothner
(01 Apr 2022 23:50 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Ray Dillinger
(02 Apr 2022 00:01 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Per Bothner
(02 Apr 2022 00:35 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Linas Vepstas
(10 Apr 2022 23:46 UTC)
|
Re: [scheme-reports-wg2] Threads and futures
Linas Vepstas
(27 Mar 2022 16:54 UTC)
|
On 3/23/22 15:17, Dr. Arne Babenhauserheide wrote: > Marc Nieper-Wißkirchen <xxxxxx@gmail.com> writes: >> What Scheme does not yet have, though, is an efficient and usable >> idiom to write generic algorithms à la those in the C++ template >> library. > Having waited a lot for C++ compiles, I do not consider these efficient. > They *are* runtime efficient, but they have a huge compile-time cost. > At the risk of talking about C/C++ in a scheme forum, I'm going to decide this is relevant because it's about the implementation language for a lot of scheme implementations. A simple-ish transformation on your C/C++ code cuts compile times in large projects drastically. I finally figured this out just a few months ago. C++ compile times explode so bad because there's an exponential effect when headers include other headers. A header for a basic utility can wind up getting read and parsed literally hundreds, or in pathological cases, thousands of times. Even if every time but the first it "doesn't count" because of #ifdef guards. You can cut that off by putting #ifdef guards around the #include statements in all the places the file is included from, skipping the USELESS task that C++ compilers wind up spending 99% of their time on in large projects. In every header file, you'll see something like #ifndef LIB_H at the top and #endif at the bottom. But then the file is #include'd from a hundred places, and each of those places is #included from three others, and so on..... In order to prevent the system from having to read and parse the file again, leave the above just as it is but also go to all the places in your program where you say #include "lib.h" And say instead #ifndef LIB_H #include "lib.h" #endif Seriously. Every place. *Especially* in the other header files. Bear