07.03.2019 13:45, Adriano dos Santos Fernandes wrote:
On 07/03/2019 06:52, Vlad Khorsun wrote:
Database creation time mostly contains from compiling and parsing
requests.
Unfortunately, it is slower in fb4 than fb3 and fb3 is much slower
than fb25.
IIRC, it was said here sometime ago and some improvement was made, but
it is
still slow.
Do you know why it's much slower, what changes made slower?
I was wrong in that fb3 is much slower than fb25, after profiling all
3 versions i see that it is fb25 is much slower in requests compiling.
But fb4 is really slower than fb3 at both compiler and executor. There
are many small reasons, the most important that i found is:
- UNICODE_FSS is replaced by UTF8 in system relations - thus many checks
that was not run in fb3 now executed in fb4
- metadata length in fb4 is two times more than in fb3 - it makes many
checks run slower accordingly
I just committed few patches and have few more things to ask here:
- There is few methods like ExprNode::dsqlAggregateFinder:
virtual bool dsqlAggregateFinder(AggregateFinder& visitor)
{
bool ret = false;
NodeRefsHolder holder(visitor.getPool());
getChildren(holder, true);
for (NodeRef* i = holder.refs.begin(); i != holder.refs.end(); ++i)
ret |= visitor.visit(i->getExpr());
return ret;
}
Is it really necessary to check all NodeRef's or we could stop when
visitor.visit()
returns true ?
Is it really necessary to collect child nodes in this case(s) ?
- According to profiler, EngineCallbacks::validateLength takes visible part of
execution cost. I noticed that during assignment of string it is called twice
for the same data: for the "from" node and than for the "to" node.
Is it possible to skip (or simplify) second validation if "to" node in the
same
charset as "from" node and have enough room to fit data ?
Regards,
Vlad
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
