Performance issues (Xtensive.Orm 7.1.1 and net7.0) #358
Comments
|
This is definitely a problem, does anyone have information about potential fixes? |
|
Bump! I also noticed a major performance issue with .NET 8 after migrating from .NET Framework. Do you have any advices on this @alex-kulakov @SergeiPavlov? |
|
Hello everyone, @niikoo, @gkverneland, @ketiovv As far as I remember 7.1 is declared and build for NET 5 and 6. So we didn't test it on NET 7 nor NET 8 environment. Can you provide some exact scenarios where it is noticeable so we could track what possible changes may be the cause. Just regular queries, some of them or all of them? Would be good if you and me had the same benchmark query or something to check it. Is this include only translation or entire roundtrip from executing Expression to getting results? Chose some query or something else that bothers you and post some performance numbers for
I will try to reproduce it all along on latest 6.0, 7.0 and 7.1 versions and post some numbers too. Let's figure it out. Secondly, I need more info about DeadlockException to investigate it, just saying that deadlock appears gives me zero information about how to at least reproduce scenarios so we could fix it. |
|
Thanks for you positive response. We have noticed worse performance across the system without being able to identify exactly where the difference is. You mentioned running 7.1.1 on .Net Framework 4.8, but it does not look like 7.1.1 targets that framework. Would it be possible to make version 6 run on .net 8? That would make it easier for us to do a fair comparison. Thanks in advance. |
|
Hi @gkverneland, Pardon me, you are right about 7.1.1 on .Net Framework. If you say it is all across the system then it might be also new framework contributing to the issue, because, for example, Domain building process wasn't changed drastically, there were some improvements, thanks to Sergei and the company he works for (their project is big and they really fight for performance of DataObjects), but nothing really big happened with domain building. We can compare domain building for starter, I have a model of 200 entities and around 10 associations per entity, I believe that it would be good for performance measurements. To eliminate variable of network interactions and database actions performance I would choose building domain in Skip mode, another option is to stop domain building right before translated upgrade actions executed. this would also eliminate impact of database almost completely. Speaking of query translation, there was serious change of last step of translation - when we visit SqlDom expressions to translate them to result string for DbCommand. I remember that I checked performance of those changes on a number of query cases and it was at least not worse than before, memory efficiency increased though. I have everything I need to compare domain building performance. I will start with it for following cases:
Query translation is a different story, it really depends on complexity of queries because it affects size of expression tree and also methods that are executed throughout translation. I would like to have an example of queries you usually execute in your project as a benchmark. The provider (sqlserver, postgresql, mysql, etc.) you use is important because translation to result string is in assembly of provider. So I need this info from you. |
|
Unfortunately, I couldn't run all the benchmarks for now only results for DO v6.0. Projects for different frameworks and DataObjects.Net versions are ready but I haven't got enough time to gather all results. I could publish the projects I use for benchmarking, but later. Here is a portion of numbers of the same model set and two ways of building Domain
Domain model contains 200 of entities similar to this [HierarchyRoot]
[Index("Int16Field")]
[Index("Int32Field")]
[Index("Int64Field")]
[Index("FloatField")]
[Index("DoubleField")]
public class TestEntity12 : Entity
{
[Key, Field]
public long Id{get;set;}
[Field]
public bool BooleanField {get;set;}
[Field]
public Int16 Int16Field {get;set;}
[Field]
public Int32 Int32Field {get;set;}
[Field]
public Int64 Int64Field {get;set;}
[Field]
public float FloatField {get;set;}
[Field]
public double DoubleField {get;set;}
[Field]
public DateTime DateTimeField {get;set;}
[Field]
public string StringField {get;set;}
[Field]
[FullText("English")]
public string Text {get;set;}
[Field]
public TestEntity11 TestEntity11{get;set;}
[Field]
public TestEntity10 TestEntity10{get;set;}
[Field]
public TestEntity9 TestEntity9{get;set;}
[Field]
public TestEntity8 TestEntity8{get;set;}
[Field]
public TestEntity7 TestEntity7{get;set;}
[Field]
public TestEntity6 TestEntity6{get;set;}
[Field]
public TestEntity5 TestEntity5{get;set;}
[Field]
public TestEntity4 TestEntity4{get;set;}
[Field]
public TestEntity3 TestEntity3{get;set;}
[Field]
public TestEntity2 TestEntity2{get;set;}
[Field]
public TestEntity1 TestEntity1{get;set;}
}I used SQL Server 2016 as database (installed on the same PC). Benchmarks use cold start and 1 run to eliminate possible cache influence. Every table below is a result of one run of executable file. Number of projects targeting different framework used the same packages of DataObjects.Net (v 6.0.12). So... .Net Framework 4.8 (.NET Framework 4.8.1 (4.8.9181.0))Skip Mode results
Recreate mode results
.Net Core 2.1 (.NET Core 2.1.30 (CoreCLR 4.6.30411.01)Skip Mode results
Recreate mode results
.NET 5 (.NET 5.0.17 (5.0.1722.21314))Skip Mode results
Recreate mode results
.NET 6 (.NET 6.0.25 (6.0.2523.51912))Skip Mode results
Recreate mode results
.NET 7 (.NET 7.0.14 (7.0.1423.51910))Skip Mode results
Recreate mode results
.NET 8 (.NET 8.0.0 (8.0.23.53103))Skip Mode results
Recreate mode results
|
|
I have finished domain build benchmarking. Probably I should've explained why I chose Skip. The key feature of Skip upgrade mode is that it assumes that database has already been upgraded. Recreate. This mode drops everything it can in database and creates entire structure of database. If it is done on already empty database it benchmarks states comparison process (current state of domain and current state of database). It also benchmarks efficiency of CREATE query translation (tables, foreign keys, indexes, etc.), in other words it benchmarks translation to string (to a certain extend). Why I didn't use Disclamer.
For better understanding of how different versions of code perform I will arrange tables of results by Framework where every table is one of versions of DataObjects.Net. Our base line is .Net Framework 4.8 with DO 6.0.12, which looks like this
Let's start with .NET 8 .NET 8 (.NET 8.0.0 (8.0.23.53103)) v6.0.12
v7.0.0
v7.0.1
v7.0.3
v7.1.1
|
.NET 7 (.NET 7.0.14 (7.0.1423.51910))v6.0.12
v7.0.0
v7.0.3
v7.1.1
.NET 6 (.NET 6.0.25 (6.0.2523.51912))v6.0.12
v7.0.0
v7.0.1
v7.0.3
v7.1.1
.NET 5 (.NET 5.0.17 (5.0.1722.21314))v6.0.12
v7.0.0
v7.0.1
7.0.3
v7.1.1
|
.Net Core 3.1 (.NET Core 3.1.32 (CoreCLR 4.700.22.55902, CoreFX 4.700.22.56512))v6.0.12
v7.0.0
v7.0.1
v7.0.3
No result for 7.1.1, no support for this framework |
|
We can see that:
Assuming that domain lifetime almost equals application lifetime, we can understand that memory efficiency of domain is I will revisit changes that we made in 7.0.1 to and try to find out what was the cause of performance drop, we will try to gain it back. @niikoo, @ketiovv, @gkverneland, Take a look at the results. |
|
The projects I used for benchmarking I published here https://github.com/alex-kulakov/domain-building-perf-check |
|
@alex-kulakov Thanks for your information and testing. It is sad to see that performance is worse with newer frameworks and we're looking forward to your further investigations on why version 7.x.x seems to be slower than 6.x.x. Btw, our concern is not mainly the startup time, but the performance while the system is running. Have you done testing related to heavy workloads in a multi-threaded application with small and large transactions going on at the same time? |
|
@gkverneland, I agree that startup is not very important, for startup memory efficiency is important and as you can see we managed to improve it significantly. Secondly, speaking of performance during normal work, I asked you guys what type of queries (or something else) bothers you. I already told that I can create a query, but it may not represent your usual queries. This is important. Since no one gave me one, query benchmarks will be my fantasy, probably unrealistic. :)
No, we haven't. The thing is that applications are different. Some of them use query caching heavily, some don't; some of applications use session tweaking to have better performance on row inserts/updates/deletions, and some don't; some of applications use query batching and some don't. And list of differences goes on and on. How should I test of all variations the user can have in his code? I would do only tests of all combinations instead of making actual changes in one particular part of ORM responsibility. Probably the most important part is queries. If we speak about query execution there are several layers that contributes to overall performance:
We can't control first 4 layers, we should not be responsible for them. I can benchmark 5th and 6th. The 5th will show how fast and efficient expression is transformed to plain text of query. This is what I'm going to measure, for this purpose I'm not going to execute DbCommands and stop on getting SQL query string. The 6th layer benchmarks are harder because on the 4th layer each client library implements receiving results differently - some use direct reading of results from DbDataReader, others load data to internal collection and then give results. This makes benchmark results of one storage not applicable to others. But no one answered to my question about provider you, guys, use. I will skip benchmarking this part. Next part is persisting changes to database. There weren't many changes in this part of DataObjects.net so its performance is mostly dictated by .NET (its improvements and degradations :), we saw them in example of 6.0 in pair with different frameworks). This part depends on relations in model because it uses graphs to order insert/update/delete operations. For now, I skip benchmarking it unless you are interested in this. Next part - session openings, transactions openings/commits/rollbacks. It is simple here, mostly it is dictated by client library and database. We do have layers of abstraction that wraps You say about "transactions going at the same time". Correct me if I'm wrong but to me this a database responsibility, not ours. It is also partially your responsibility as developer because you decide how to manage transactions - when to open them and when to close, durations and isolation levels. We can't do much about it. Our job is to call Next, multithreaded performance. First of all, we see Session as a unit of parallelism. One Session one thread, this concept allows asynchronous execution but not parallel execution. We declared it in documentation. We develop with this assumption in mind, I hope you do the same. Sergei's team discovered that our domain-level caches are slow on high number of threads because of locks, these collections were developed long time. We replaced our collections with counterparts from BitFaster library. This happened in 7.1. By doing so multi-threaded performance of domain-level LRU caches was improved significantly. Other global caches use collections from System.Collections.Concurrent namespace, the collections are lock-free so they should be fine. I believe that if we (me and you guys) start searching for exact cases, we will be more productive and chances of improving overall performance by improving exact weaknesses are higher. This is why I asked about particular cases that stand out on your side and should be addressed. |
|
Hello, I'm back with additional results, this time for query translation measurements. I've created following LINQ query (if somebody wants to provide his own query, I don't mind, I would glad to benchmark close-to-life query): public static IQueryable<VehicleDto> MakeQuery(Session session)
{
return session.Query.All<IVehicle>()
.Where(iv => iv.EnergySource == EnergySource.DieselFuel
|| iv.EnergySource == EnergySource.Gasoline
|| iv.EnergySource == EnergySource.Electricity
|| iv.ModelName.StartsWith("A") || iv.ModelName.StartsWith("B") || iv.ModelName.StartsWith("C")
|| iv.ModelName.Contains("C") || iv.ModelName.Contains("D") || iv.ModelName.Contains("E")
|| iv.Type.In(IncludeAlgorithm.ComplexCondition,
VehicleType.Car, VehicleType.Truck, VehicleType.Ship, VehicleType.PersonalMobilityDevice)
|| (iv.Id > 100 && iv.Id < 1_000_000)
|| (iv.Timestamp.Year - iv.Timestamp.Day) > 1500
|| (iv.Timestamp.AddDays(3) > DateTime.UtcNow)
)
.LeftJoin(
session.Query.All<Person>()
.Where(p => p.FirstName.Contains("A") || p.FirstName.Contains("B") || p.FirstName.Contains("C")
|| p.FirstName.StartsWith("D") || p.FirstName.StartsWith("Y") || p.FirstName.StartsWith("Z")
|| p.Immovables.Count > 0
|| (p.Id > 100 && p.Id < 1_000_000)
|| (p.Timestamp.Year - p.Timestamp.Day) > 1500
|| (p.Timestamp.AddDays(3) > DateTime.UtcNow)
)
,
iv => iv.Owner.Id,
p => p.Id,
(iv, p) => new { IVehicle = iv, VehicleOwner = p })
.LeftJoin(
session.Query.All<VehicleManufacturer>()
.Where(vm => vm.Country.StartsWith("A") || vm.Country.StartsWith("B") || vm.Country.StartsWith("C")
|| vm.Country.Contains("C") || vm.Name.Contains("D") || vm.Name.Contains("Z")
|| (vm.Id > 100 && vm.Id < 1_000_000)
|| (vm.Timestamp.Year - vm.Timestamp.Day) > 1500
|| (vm.Timestamp.AddDays(3) > DateTime.UtcNow))
,
a => a.IVehicle.Manufacturer.Id,
vm => vm.Id,
(a, vm) => new { IVehicle = a.IVehicle, VehicleOwner = a.VehicleOwner, VehicleManufacturer = vm })
.LeftJoin(
session.Query.All<VehicleRegistrationInfo>()
.Where(ri => ri.LicensePlate.StartsWith("B")
|| ri.LicensePlate.StartsWith("C")
|| ri.LicensePlate.EndsWith("Z")
|| ri.LicensePlate.EndsWith("Y")
|| (ri.Id > 100 && ri.Id < 1_000_000)
|| (ri.Timestamp.Year - ri.Timestamp.Day) > 1500
|| (ri.Timestamp.AddDays(3) > DateTime.UtcNow))
,
a => a.IVehicle.RegistrationInfo.Id,
ri => ri.Id,
(a, ri) => new {
IVehicle = a.IVehicle,
VehicleOwner = a.VehicleOwner,
VehicleManufacturer = a.VehicleManufacturer,
VehicleRegistrationInfo = ri })
.LeftJoin(
session.Query.All<AddressInfo>()
.Where(ai => ai.City.Length > 5 || ai.Address.Length > 10 || ai.ContactType == ContactType.Address),
a => a.VehicleRegistrationInfo.RegistrationAddress.Id,
ra => ra.Id,
(a, ra) => new {
IVehicle = a.IVehicle,
VehicleOwner = a.VehicleOwner,
VehicleManufacturer = a.VehicleManufacturer,
VehicleRegistrationInfo = a.VehicleRegistrationInfo,
VehicleRegistractionAddress = ra
})
.Select(a => new VehicleDto
{
VehicleId = a.IVehicle.Id,
VehicleRecordTimestamp = a.IVehicle.Timestamp,
VehicleModelName = a.IVehicle.ModelName,
VehicleVinNumber = a.IVehicle.VinNumber,
VehicleEngineSource = a.IVehicle.EnergySource,
VehicleEnginePower = a.IVehicle.EnginePower,
VehicleType = a.IVehicle.Type,
VehicleOwner = new VehicleOwnerDto
{
OwnerId = a.VehicleOwner.Id,
OwnerRecordTimeStamp = a.VehicleOwner.Timestamp,
OwnerFirstName = a.VehicleOwner.FirstName,
OwnerLastName = a.VehicleOwner.LastName,
NumberOfVehicles = a.VehicleOwner.Vehicles.Count,
NumberOfImmovables = a.VehicleOwner.Immovables.Count,
},
VehicleManufacturer = new VehicleManufacturerDto
{
ManufacturerId = a.VehicleManufacturer.Id,
ManufacturerRecordTimeStamp = a.VehicleManufacturer.Timestamp,
ManufacturerName = a.VehicleManufacturer.Name,
ManufacturerCountry = a.VehicleManufacturer.Country
},
VehicleRegistrationInfo = new VehicleRegistrationInfoDto
{
RegistrationId = a.VehicleRegistrationInfo.Id,
RegistrationRecordTimeStamp = a.VehicleRegistrationInfo.Timestamp,
RegistrationLicensePlate = a.VehicleRegistrationInfo.LicensePlate,
RegistrationAddress = new RegistrationAddressDto
{
AddressId = a.VehicleRegistractionAddress.Id,
AddressPostCode = a.VehicleRegistractionAddress.PostCode,
AddressCountry = a.VehicleRegistractionAddress.Country,
AddressCity = a.VehicleRegistractionAddress.City,
AddressAddress = a.VehicleRegistractionAddress.Address
}
}
});
}The idea in the query was to have different statements of SQL query. I didn't benchmark the whole round-trip (from linq to sql command than execute and materialize) because it would bring network and RDBMS performance to the equation and dilute results. DataObjects.Net has a built-in service called So,
To have final results more precise, I moved results of previous steps (if any exists) out of benchmark scope. For instance, benchmark of [MemoryDiagnoser]
[Orderer(BenchmarkDotNet.Order.SummaryOrderPolicy.Declared)]
[RankColumn]
public class QueryBuilderStepFourBenchmark : TranslationBenchmarkBase
{
private QueryBuilder queryBuilder;
private QueryTranslationResult translationResult;
private SqlCompilationResult sqlCompilationResult;
private QueryRequest request;
public override void BeforeEveryIteration()
{
base.BeforeEveryIteration();
queryBuilder = session.Services.GetService<QueryBuilder>();
translationResult = queryBuilder.TranslateQuery(cachedQuery); //Step #1
sqlCompilationResult = queryBuilder.CompileQuery(translationResult.Query); // Step #2
request = queryRunner.CreateRequest(queryBuilder, sqlCompilationResult, translationResult.ParameterBindings); // Step #3
}
public override void AfterEveryIteration()
{
queryBuilder = null;
request = null;
sqlCompilationResult = null;
translationResult = null;
base.AfterEveryIteration();
}
[Benchmark]
public void CreateQueryCommand()
{
_ = queryRunner.CreateQueryCommand(queryBuilder, request); // Step #4, which we actually benchmark
}
public QueryBuilderStepFourBenchmark() : base()
{
}
}I believe such approach is right for getting correct picture of specific step. I performed benchmarks for v6.0.12, v7.0.0, v7.0.1, v7.0.2, v7.0.3, v7.0.4 and v7.1.1 across different frameworks and grouped results by framework and ordered by DO version. |
|
Translate() method results
I can clearly see how newer versions of .NET kill performance. After performance drop in .NET Core 2.1 and 3.1, it gets closer to .Net Framework 4.x levels in NET5, NET6 is still OK and then it drops significantly. CompileQuery() method results
Same story. Performance recovers in NET 5 and NET 6 and then deeps down in NET 7 and NET 6. CreateRequest() results
Story repeats. I already know how to slightly improve this region but since this part is basically several objects' instantiations and copying items of collection, we can do almost nothing for this part of translation. I did some research, maybe 1-2 nanoseconds and some memory efficiency will be gained. I already committed the changes in my private copy of the repo. CreateCommand() results
Here, unfortunately I see significant drop in version 7.1.1. but framework also contribute to losses. In 7.1.1 we changed SQL DOM expression translation to Nodes, which might have shifted some compute time to final preparation, but I'm not sure. Currently I'm working with this part, trying to find points for improvement. I left the big parts to be last, because they are much complicated and will take a lot of time to find ways to improve. I will try to compensate losses caused by .NET 7 and .NET 8, .NET5 and NET6 will also be improved. |
|
@gkverneland, @niikoo, @ketiovv take a look. I'd like to know your thoughts. |
|
@alex-kulakov Thanks a lot for your investigations so far. It is sad to see that for Xtensive.Orm, all tests show that performance is way worse with .Net 8 than before. I see that version 6.x.x is not included in your tests for .Net 7 and .Net 8, have you tested that combination? It would be very interesting to have tests where the Xtensive.Orm code is as similar as possible. We have been able to run version 6.x.x with .Net 7 and 8, and can give you the fork if you are interested. Btw, have you seen this issue about performance for expression compilation? Is it relevant for this project? |
Hello! Thanks for taking the time to reply to us. Do you have a link to the benchmark project that you've used here: #358 (comment) |
Yes, It is not included because there are some breaking changes in .net that prevented usage of already built packages. The benchmark project and Domain build successfully but queries don't work. To be honest, I don't want to resolve all the issues connected with migration once again just for benchmarks, I just assumed that 7.0.0 is good enough to substitute 6.0.12. If you have a version of 6.0.12 with changes that can be used in .net 5, 6 and so on I would get such version in form of packages. I believe it will be fastest way. Put some suffix in Version.props file before build, for instance I'll gladly include it to benchmarks and post results here.
Not yet, but I will check it out. Thank you for pointing me to these two issues. Something outside DataObjects.Net ruins the performance for sure, and since translation uses reflection a lot there must be degradation of performance somewhere there. |
Not yet, it is not a problem to post. I just use the projects to monitor how my changes affect performance, so it has some garbage right now. If you are interested, I'll clean it up and post as repo as before, it is not a problem, I have nothing to hide 😉 |
|
BTW guys, do you use "cached queries" feature of DataObjects.Net? I'm talking about session.Query.Execute() group of methods. Though, not all the queries can be transformed into cacheable form, many of them can be, which allows to skip the most time-consuming part of query translation after first run of the query, so you might be interested in such option. |
|
The repo is here https://github.com/alex-kulakov/query-translation-perf-check |
|
Hello guys, @gkverneland, @niikoo, @ketiovv I have revised code and found some points for improvement, they are posted as the PR - #392, They are small, no drastic difference but still, also not all of them are connected with the test query in the query-translation-perf-check repository. During my investigation I captured this The functions are sorted by CPU Self time, which shows the most inefficient methods on the top. As you can see most percentage of time spent in external or native code. The items that take 3.57% of time are very small, for instance ExtendedExpression constructor is a constructor that assigns few properties. It doesn't mean that our code is the most efficient, I believe there are still points for improvement like in any app/framework/etc, but it shows that outside code impacts performance seriously. |
|
Actually we can reduce the amount of time spent in External/Native code by improving callers of that code. For example: I found O(n²) - complexity algorithms where O(n) can be used: |
|
@SergeiPavlov Nice. |
I did some testing, building the servicetitan version of DO.net, and setting COMPlus_EnableWriteXorExecute=0 in the environment variables. It resulted in significant performance improvements. Could you @alex-kulakov look into this and see if you can cherry-pick the changes made by @SergeiPavlov? |
|
I glanced at the changes Sergei did and proposed, the changes can appear only in master (which is 7.2 in develop). Currently released versions will not receive them. Outside of this discussion Sergei proposed me covariant returns for cloning of certain classes (e.g SqlNode derived ones), that I successfully applied to 7.1 branch. The changes can't be applied to version older than 7.1 due to target-framework-to-language-version binding. I will also read about the option you mentioned to better understand the outcome of it. Thank you for this information. |
|
@alex-kulakov Is there a way to do something similar to EF Core's .AsNoTracking() in Xtensive.Orm? So that we can work on objects without change tracking and save changes manually? |
|
@alex-kulakov Would it be possible to have a new build of Xtensive.Orm version 7.1.x with the performance patches included? Thanks |
I believe you need to check our manual for We do it on session level because it is more flexible approach which allows to combine automatic and manual savings if needed. We also provide session methods Please try to check our manual before asking questions though it is not as good as ones microsoft provides and may lack some details but basic concepts and settings are described fairly good, I'm glad to help you anyway.😉 |
I think we'll manage to publish next 7.1.x until the end of September or in first days of October. Changes that were made in 6.0 and 7.0 are in '7.1' branch (which is like 'master' branch for 7.1.x) |
Before the release of next 7.1.x I made little investigation of how this option affects the benchmarks. I decided to do so because you said you built project with the variable so I assumed it might be beneficial to start using it during build. But then I saw this post, and according to it the option modifies behavior of runtime, in particular it has effect on memory pages by makes them read-executable by default, which was first introduced for macOS runtime. The variable has no effect on result assembly during project build, or I miss something here? I saw this during collecting data, just changing environment value affected performance (seen in query related graphs below). Don't know how about NET7 and NET8 but in NET6 it was optional behavior. Probably they have changed it to default because you said you turned it off by having env variable Anyway, I collected some results for some of benchmarks (not all of them because it is very time consuming to organize raw results into something more meaningful). I made different runs with the variable set to 0 and set to 1 on DO 7.1.1 run under NET 6, NET 7, NET 8 runtimes. Remarks on the graphs:
So. Domain build graphs (right from excel)
There is clear difference in NET 6, less difference in NET 7. NET8 has part where lines almost merged and the part where they split, since we talk about seconds, something may have effect on upper values of the range (windows does stuff in the background) or maybe it is true separation. I see the trend to have little-to-no difference in NET8. Maybe because your app is more complicated you have bigger impact or because you have different runtime (I mean Linux vs macOS vs Windows runtimes) the environment variable makes big difference, but this is only my assumption. Anyway, there is a difference in performance in NET 7. You can add to my data and we re-value the conclusion. For query benchmarks I chose two steps to monitor - compilation of translated query (which seems to be quite long, but not so long) and creation of query command (because it is kind of short). I decided to get little more data and made 30-ish runs 'Create command' graphs
Once again, quite big difference in NET 6, which gets smaller in NET7 and in NET8 lines almost merge together 'Compilation of translated query' graphs
There is an anomaly on NET6 graph, the gap got shirked, maybe something system does in the background affected (forgive me, I don't want to re-do it one more time), but still, there is a difference, and if we apply the same trend of having the biggest gap in NET6, we can see it. NET7 still has difference, but what is most important that NET8 has almost no gap, it is negligible (apart from another small anomaly), we can see the trend. @niikoo, since you have mentioned the variable, can you have a look and check me, maybe add something to the results? |
Thank you for your reply. Setting that variable will not affect the build or assembly as far as I've understood, only effective when running the program. One question, did you include the patches referenced in the comment linked below, before running the benchmarks? |
No, the reason is that I wanted less variables to control and affect results. The data gathered for publicly available 7.1.1 package. I think in this case anyone can repeat what I did and come up with their results to compare.
The same. 😁 |
Okay. I had to use that patch in addition to the environment variable to get the performance in net8 to match net6/net48 |
Hello!
We have a project running on Xtensive.Orm 6.1.1 and .net Framework 4.8 and we have migrated it to Xtensive.Orm 7.1.1 and net7.0. We experience that database tasks are slower than before, even without any changes to the models. We also get many DeadlockExceptions. Is there anything we need to do or any changes in Xtensive.Orm 7.1.1 that affects the performance?
The text was updated successfully, but these errors were encountered: