alt Hacker NewsIn other languages, you can find the lines where the performance problems are and fix them without breaking the abstraction everywhere else.
In other languages, you can find the lines where the performance problems are and fix them without breaking the abstraction everywhere else.
I think this is very well phrased, and I would argue the same holds for Prolog too.
In my opinion, a key difference between Prolog and other languages in that regard is one of degree, not kind: Compared to other languages, addressing performance problems in Prolog engines tends to have far greater effects on Prolog programs, because so much is implicit (i.e., left to the engine).
If the performance problem is not in the engine, but in the program itself, then we will face the same questions with Prolog as with other languages: How to formulate the program better, is there a better approach altogether?
For example, earlier today an interesting question regarding performance was posted in the Scryer discussions:
https://github.com/mthom/scryer-prolog/discussions/3341
The comparison in this case is between Gecode and Scryer on a seemingly simple but nontrivial combinatorial task. What is the problem here? Most likely the Scryer engine itself can be improved. And also very likely, there are better ways to model the task, and also better search strategies, and these tend to have far greater performance impact than the base language, and these questions remain also if we change the base language.
In my opinion, these questions regarding different kinds of formulations tend to be more frequently associated with Prolog than with other languages because Prolog is more frequently used for complex tasks where it is not a priori clear how to even approach the problem.