Age | Commit message (Collapse) | Author |
|
This should completely eliminate the confusion between load and load_file.
Of course, for compatibility reasons we have to preserve the old variant -
it will be deprecated in a future version and subsequently removed.
|
|
The behavior on OSX is different - we don't get a I/O error so the test is
useless.
|
|
Computed offsets for documents with nodes that were added using append_buffer
or newly appended nodes without name/value information were invalid.
|
|
|
|
|
|
Calling memcpy(x, 0, 0) is technically undefined (although it should usually
be a no-op).
|
|
|
|
added some tests to force invalid buffer and size = 0
|
|
This lets us do fewer null pointer checks (making printing 2% faster with -O3)
and removes a lot of function calls (making printing 20% faster with -O0).
|
|
To get more benefits from constant predicate/filter optimization we rewrite
[position()=expr] predicates into [expr] for numeric expressions. Right now
the rewrite is only for entire expressions - it may be beneficial to split
complex expressions like [position()=constant and expr] into [constant][expr]
but that is more complicated.
last() does not depend on the node set contents so is "constant" as far as
our optimization is concerned so we can evaluate it once.
|
|
If a filter/predicate expression is a constant, we don't need to evaluate it
for every nodeset element - we can evaluate it once and pick the right element
or keep/discard the entire collection.
If the expression is 1, we can early out on first node when evaluating the
node set - queries like following::item[1] are now significantly faster.
Additionally this change refactors filters/predicates to have additional
metadata describing the expression type in _test field that is filled during
optimization.
Note that predicate_constant selection right now is very simple (but captures
most common use cases except for maybe [last()]).
|
|
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1081 99668b35-9821-0410-8761-19e4c4f06640
|
|
A page can fail to allocate during attribute creation; this case was not
previously handled.
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1080 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1077 99668b35-9821-0410-8761-19e4c4f06640
|
|
Also fix MSVC6 compilation (make convertions to function pointers explicit).
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1076 99668b35-9821-0410-8761-19e4c4f06640
|
|
More tests for out-of-memory and other edge conditions
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1075 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1074 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1071 99668b35-9821-0410-8761-19e4c4f06640
|
|
This should never happen but can improve debugging experience for
work-in-progress changes since that avoids memcpy() into negative memory
space (debugger can't backtrace from failed memcpy since it does not set
up the stack frame).
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1070 99668b35-9821-0410-8761-19e4c4f06640
|
|
Some steps relied on step_push rejecting null inputs; this is no longer
the case. Additionally stepping now more rigorously filters null inputs.
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1069 99668b35-9821-0410-8761-19e4c4f06640
|
|
It's unfortunate that we can even do that...
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1068 99668b35-9821-0410-8761-19e4c4f06640
|
|
Sometimes when evaluating the node set we don't need the entire set and
only need the first element in docorder or any element. In the absence of
iterator support we can still use this information to short-circuit
traversals.
This does not have any effect on straightforward node collection queries,
but frequently improves performance of complex queries with predicates
etc. XMark benchmark gets 15x faster with some queries enjoying 100x
speedup on 10 Mb dataset due to a significant complexity improvement.
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1067 99668b35-9821-0410-8761-19e4c4f06640
|
|
select_node is shorter and mistyping nodes as node or vice versa should
not lead to any issues since return types are substantially different.
select_single_node method still works and will be deprecated with an
attribute and removed at some point.
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1065 99668b35-9821-0410-8761-19e4c4f06640
|
|
This method is equivalent to xml_node::select_single_node. This makes
select_single_node faster in certain cases by avoiding an allocation and -
more importantly - paves the way for future step optimizations.
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1064 99668b35-9821-0410-8761-19e4c4f06640
|
|
Use descendant-or-self::node() transformation for self, descendant and
descendant-or-self axis. Self axis should be semi-frequent; descendant
axes should not really be used with // but if they ever are the complexity
of the step becomes quadratic so it's better to optimize this if possible.
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1063 99668b35-9821-0410-8761-19e4c4f06640
|
|
CLR x64 JIT does not implement ceil() properly (ceil(-0.1) returns
positive zero instead of negative zero). Disable the relevant portions of
tests so that everything else is green...
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1062 99668b35-9821-0410-8761-19e4c4f06640
|
|
When looking for an attribute by name, finding the first attribute means
we can stop looking since attribute names are unique. This makes some
queries faster by 40%.
Another very common pattern in XPath queries is finding an attribute with
a specified value using a predicate (@name = 'value'). While we perform an
optimal amount of traversal in that case, there is a substantial overhead
with evaluating the nodes, saving and restoring the stack state, pushing
the attribute node into a set, etc. Detecting this pattern allows us to
use optimized code, resulting in up to 2x speedup for some queries.
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1061 99668b35-9821-0410-8761-19e4c4f06640
|
|
The actual condition for the optimization is invariance from context list
-- this includes both position() and last().
Instead of splitting the posinv concept just include last() into
non-posinv expressions - this requires sorting for boolean predicates that
depend on last() and do not depend on position(). These cases should be
very rare.
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1060 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1059 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1054 99668b35-9821-0410-8761-19e4c4f06640
|
|
translate() with constant arguments now uses a 128-byte table and a table
lookup instead of searching characters in the source string. The table is
generated during query optimization.
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1052 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1051 99668b35-9821-0410-8761-19e4c4f06640
|
|
Also fixes PUGIXML_NO_STL compilation and makes it possible to build with
any version of new Windows SDK.
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1044 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1040 99668b35-9821-0410-8761-19e4c4f06640
|
|
pointer alignment
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1039 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1038 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1035 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1033 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1030 99668b35-9821-0410-8761-19e4c4f06640
|
|
This test has previously caused a stack overflow on x86/MSVC.
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1028 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1022 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1020 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1017 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1016 99668b35-9821-0410-8761-19e4c4f06640
|
|
This test previously caused a stack overflow on x86/MSVC.
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1015 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1010 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1003 99668b35-9821-0410-8761-19e4c4f06640
|
|
When allocating new pages, make sure that the page has at least 1/4 of the
base page size free. This makes sure that we can do small allocations after
big allocations (i.e. huge node lists) without doing a heap alloc.
This is important because XPath stack code always reclaims extra pages after
evaluating sub-expressions, so allocating a small chunk of memory and then
rolling the state back is a common case (filtering a node list using a
predicate usually does this).
A better solution involves smarter allocation rollback strategy, but the
implemented solution is simple and practical.
git-svn-id: https://pugixml.googlecode.com/svn/trunk@999 99668b35-9821-0410-8761-19e4c4f06640
|
|
git-svn-id: https://pugixml.googlecode.com/svn/trunk@997 99668b35-9821-0410-8761-19e4c4f06640
|