Comments (27)
I've converted all test where possible (GitHub issues not yet)
But the ones wich include a Expression created from c# compiler are not converted! I also think we should test c# compiler generated expressions, so we should not change this tests. If we need them also for LightExpression we need to create new ones.
from fastexpressioncompiler.
As you now already have breaking changes, maybe it's a good idea to remove obsolete API's ?
from fastexpressioncompiler.
I now changed the return type to MemberExpression
from fastexpressioncompiler.
3 Convert Expression to ExpressionInfo and handle the latter
I may use the approach from sum-types to make ExpressionInfo cases a structs under the ExpressionInfo class, implementing the same interface. That's will ensure the performance of conversion from Expression to EI struct.
Given that C# 7 enables in
(by ref) semantics for struct parameters, the result IE can be passed to TryEmit..
methods in efficient manner.
This + migrating to C# 7+ may be a goal for v2.0
from fastexpressioncompiler.
The current strategy makes the Code much more complex. wouldn't it be possible to Generate Code only for normal "Expressions" and create a second .cs file via T4 for ExpressionInfo?
So we put "using static System.Linq.Expressions.Expression;" and change this via the T4 Template for ExpressionInfo?
The current approach makes the Code very complicated where it not needs to be.
from fastexpressioncompiler.
Ok may be we are at the point to split.
I did not consider T4 but did consider a split.
Bonus points except code simplification are:
- Not performance loss due casting and matching Expr vs ExpressionInfo, and no need in proxy types.
- The full parity beteen both will be automatic.
Technically, how the template should look like?
<# T4 directives ... #>
using static FastExpressionCompiler.ExpressionInfo;
<#@ include File="$(SolitionDir)\Shared\FastExpressionCompiler.cs" #>
from fastexpressioncompiler.
I think you should have at least 2 source files.
One with the complete parsing code and "using static System.Linq.Expressions.Expression;" at the top.
One file with the complete ExpressionInfo type definitions.
And a T4 Template wich replaces the "using static System.Linq.Expressions.Expression;" at the top.
from fastexpressioncompiler.
Putting using static
aside there other things to consider.
I want and do in DryIoc use both Ecpr and ExprInfo in the same class. That means I need to prevent conflicts via either names (Info
suffix) or via different namespaces.
There are method that accept Expr and ExprInfo as parameters. I would like to remove the midfke ground object
parameters. In this case using static
won't help, cause parameter names should be fully stated.
Then we may remove Info
suffix, but need to use a new namespace, to enable non-conflicting usage.
from fastexpressioncompiler.
I think we may start with moving ExpressionInfo
to separate file.
Then remove all the noize from FEC related to ExprInfo.
At the end we may just copy FEC.cs to new project with ExprInfo.cs and make it work, preserving minimal changes. Better 1, or 2 line changes.
Then move all tests for ExprInfo to separate project.
If everything compiles - works, it will be a very good step.
Then the new FECWithExprInfo package.
We may even dismiss or postpone T4.
from fastexpressioncompiler.
when will you start doing this?
from fastexpressioncompiler.
Depends. I may start after merging your requests, maybe later Today or Tomorrow.
I but I don't think I'll finish in one swoop. Maybe a couple of days.
from fastexpressioncompiler.
If I should help anything, tell me.
from fastexpressioncompiler.
The work is going on in dev
branch
from fastexpressioncompiler.
Good idea!
from fastexpressioncompiler.
maybe we should also modify the tests that most of them work with Expression and LightExpression?
from fastexpressioncompiler.
maybe we could also do this with conditional compilation?
from fastexpressioncompiler.
Already doing so. At the end I will link all the Unit and Issue tests (which is make sense) to the respective LE tests.
You may check AssignTests
and BockTests
already for how I am doing so.
from fastexpressioncompiler.
split is finished?
from fastexpressioncompiler.
The main part is finished.
What remains is the incremental addition of Tests (Unit and Issues) for FEC.LE, and adding whatever is missed in FEC.LE.Expression.cs
The tests may be added one-by-one without affecting other fixes. Therefore moving to master.
from fastexpressioncompiler.
@jogibear9988 , @dzmitry-lahoda ,
If you have possibility to help with adding the rest of the tests for LE.Expression,
I would appreciate your help.
Just put comment here about what tests you are migrating.
Check my commits above for guideline.
from fastexpressioncompiler.
I may cover ref
related tests within several weeks if not yet. Other vice I may do math
operators tests.
from fastexpressioncompiler.
I'm working on all the GH issues tests. think 20min
from fastexpressioncompiler.
problem:
this line:
expression = field == null ? Property(expression, property) : Field(expression, field);
does not work with light expression, because Property && Field return different types! what should I do?
from fastexpressioncompiler.
I now changed the return type to MemberExpression
I think this is fine, not sure why it was two expressions without common parent.
Usually, I am decompiling original System...Expression.cs
and see what's there.
But the ones wich include a Expression created from c# compiler are not converted! I also think we should test c# compiler generated expressions, so we should not change this tests.
Yep, that's why I've already #if
ed them out. We may consider to do tests on respective manually built exprs, but not now.
from fastexpressioncompiler.
They do have a common parent: MemberExpression
But the Return Type of the Static method of LightExpression class was to specific. It does only return a MemberExpression on the MS Code. And so the type of the variable is to specific, and C# could not compile!
from fastexpressioncompiler.
finished?
from fastexpressioncompiler.
I will uncomment benchmarks. Will check if any problems in using FEС and FEC.LE together. Will fix and close.
from fastexpressioncompiler.
Related Issues (20)
- EmitCall is for the varargs method and should not be used for normal convention
- Is it possible to implement ref local variables? HOT 11
- InvalidProgramException on compiling an expression that returns a record which implements IList HOT 4
- Make cast to target type controlled in config flags instead for diagnostics HOT 1
- Error when loading struct parameters closed by the nested lambda e.g. predicate in Linq
- Optimize nested lambdas with closures
- Hack DynamicMethod HOT 9
- xxxAssign doesn't work with MemberAccess HOT 2
- NullReferenceException when calling CompileFast() results HOT 4
- Error with converting to/from signed/unsigned integers HOT 6
- Invalid program exception HOT 8
- Improve the performance of variable lookup HOT 1
- Add RequiresUnreferencedCode attribute to types HOT 1
- Add support for up to 16 parameter Func<>/Action<> to LightExpression HOT 1
- Working with ref return values HOT 2
- FastExpressionCompiler[v3.3.4] gives incorrect results in some linq operations HOT 3
- Better diagnostics and debugging with error codes from Collect and Compile rounds HOT 2
- Fix duplicate nested lambda compilation HOT 1
- Decrease memory occupied by the LightExpression Block by storing Expression in SmallList (partly on stack) HOT 1
- Optimize any nested lambda compilation (LINQ) by compiling right after collect one-by-one HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fastexpressioncompiler.