Replies: 5 comments 3 replies
-
Thanks @zoziha and apologies for the late response! I agree this is an area where fpm could do with some improvement. It may be possible to parallelize some parts of the startup processing but it's possible that the bottleneck here is actually disk io when parsing files. Similarly, there are definitely areas where the algorithms could be improved and optimized - again this will require profiling to identify the hostpots. I like your suggestion to cache model information for dependencies and IMO that will probably provide the greatest improvement for the fewest (complex) code changes. It should be quite straightforward to cache model information for dependencies to the build folder and clear the cache if the dependency gets updated. Out of interest, which method do you use build/install fpm on Windows? |
Beta Was this translation helpful? Give feedback.
-
Thank you @LKedward very much for your reply, I think that using
Because I pay more attention to the update of the fortran-lang organization, on a new computer, I usually download the Unfortunately, the speed of accessing github from China is often not good, which also prevents more fortran Chinese users from accessing and installing |
Beta Was this translation helpful? Give feedback.
-
I got the I feel like we can use the disk cache to store the dependency tree (maybe a TOML table), and the second time we run |
Beta Was this translation helpful? Give feedback.
-
Like the ability to use Line 96 in 87dcb9b It seems possible to set up a parallel domain at Line93 to Line112 in |
Beta Was this translation helpful? Give feedback.
-
I tried to parallelize the source file parsing (see parallel-readfile for details, don't know if I did it right), but the end result didn't improve. It may be due to the
(While |
Beta Was this translation helpful? Give feedback.
-
When I use
fpm
for coding, building the dependency model and compiling the code becomes visibly slow when the dependencies are large.Especially under Windows system, it seems to be much slower to access the file system than Linux and macOS.
The current strategy of
fpm
is to first retrieve all source files, build a dependency model, and then start compiling. On Windows systems, for larger code, it will take several seconds to build a dependency model in everyfpm build
, which will give users a feeling thatfpm
is very slow.The following issues are relevant to this discussion and may improve this situation:
fpm/src/fpm.f90
Line 157 in 95dbca1
I don't learn
Rust
and I don't understand howcargo
handles this: in particular, there are enough dependent libraries and the total amount of code is large.Is there a good way to improve this problem:
fpm
under Windows?Beta Was this translation helpful? Give feedback.
All reactions