Is there decrease in application performance if I design application with either using internal DSL(Domain specific Language) or external DSL(Domain specific Language) or fluent API design patterns?
External DSLs can lead to far better performance, and usability, than internal DSLs.
The purpose of a DSL is to let an engineer specify a problem or solution succinctly and clearly, so he is able solve that problem more quickly and effectively.
To the extent the problem has no need for high performance, one can build an internal DSL out of a set of subroutines and simply call them to achieve the desired effect. It is reasonable to note that most computations are not expensive, thus the standard warning about "premature optimization".
However, many DSLs do need high performance (SQL, expert systems, lexer and parser generators). These solutions often require sophisticated algorithms (parsing, name resolution, flow analysis, boolean equation construction/simplification) to analyze the DSL specification instance provided by the engineer, and then apply special algorithms (pattern matching, FSA construction, Rete networks) perhaps along with sophisticated code generation and optimizations (query optimizations, special case handling, code motion, algebraic simplification) to produce the effective answer. In this case, internal DSLs are IMHO pretty much a disaster, because it is very hard to reason about just the API calls without getting reasoning about the rest of the language tangled into the process. It is also hard to find the boundaries of the DSL specification instance; where does it end, and just plain programming end?
In general, I think "external" DSLs, those with a specialized notation (be it text or graph) are simply easier to write (and then read). In some cases, one cannot in realize the DSL without the notation (consider LR parser generators or Rete networks; these are not practical to code by hand, you have to have external DSL and supporting tools). If the purpose is to enable engineers to solve problems many times, I believe readability and expressiveness are what you should optimize, not ease of implementation. SQL is much easier to read than any procedural pile of database table accesses. This is a win for maintenance, too; if the DSL has any success, people will want to change what they specified. The downside to an external DSL is one must design a decent specification notation for it, and that may not be easy to do or within the skills of the domain designer, and building tools to support the DSL are often considered to be difficult. (Check my bio, I have an answer for the latter).
The only good argument for an internal DSL is that it won't be used very many times, and so it isn't worth the effort to design the corresponding specification language or supporting tools. That makes me wonder about the actual utility of the DSL being proposed.