Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> LLBLGen Micro
 

Pages: 1
LLBLGen Pro Runtime Framework
LLBLGen Micro
Page:1/1 

  Print all messages in this thread  
Poster Message
Ian
User



Location:
Hertfordshire, UK
Joined on:
01-Apr-2005 16:37:36
Posted:
511 posts
# Posted on: 19-Feb-2015 19:45:11.  
How about an API for LLBLGen that does queries that match Micro ORMs for speed? So stripping out all functionality unnecessary to the most basic usage.

In fact why not take it a step further and make the query pipeline like node and the new ASP.net stuff in that you configure in only the features that are required?
  Top
daelmo
Support Team



Location:
Guatemala City
Joined on:
28-Nov-2005 23:35:24
Posted:
8109 posts
# Posted on: 20-Feb-2015 07:19:12.  
Hi Ian,

To understand your post: In this context
- What is Micro?
- What is 'the most basic usage'?
- What is the issue with the actual speed? And How a micro orm would solve it?

As a matter of fact, with the new SDK you could write your own target framework, set of templates, tasks, presets, etc. So indeed it's possible, but you have to write it Regular Smiley


David Elizondo
LLBLGen'ing (articles and code snippets) | linkedin | twitter
 
Top
Ian
User



Location:
Hertfordshire, UK
Joined on:
01-Apr-2005 16:37:36
Posted:
511 posts
# Posted on: 20-Feb-2015 17:40:11.  
I don't think I can do a very good job of answering your questions. However take a look at this article.... http://www.mattjcowan.com/funcoding/2012/02/24/adding-llblgen-to-the-dapper-benchmark-test-project/

Clearly the Micro ORMs are doing things significantly quicker.

In the comments Frans says...

Quote:

during fetching or other db interactions, some features have to be called, simply because they’re supported in the framework.


So my point is do queries without all the supported features when they're not being used.
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37869 posts
# Posted on: 21-Feb-2015 09:33:55.  
Example: for 32K entities, we're not that slow: http://pastebin.com/3eqm7bn7. In the grand scheme of things, the rest of the calls to the fetch logic also take time and it might very well be the time difference you'll see (as you'll likely fetch way less data) isn't that big, if noticable at all).

We don't write a microORM as there are already so many, and you can add them to a project with our framework without a problem: if you have a particular fetch which is faster with dapper and you need it to be the fastest possible, use dapper for that query. thing is: most microORMs fetch readonly data, so there's e.g. no change tracking with microORMs, so writing back the data you fetched might be a challenge. So in these cases use our own framework.

Our current poco fetch pipeline for poco typedviews isn't 100% optimal, there is room for improvement, however not that much before we'll have to use IL generation. (and it's still faster than e.g. OrmLite Wink) Currently the code has to take care of situations where typeconverters might be in play and other things which might slow down the fetch a bit, but if the query e.g. doesn't have those, it doesn't skip these checks.

But overall, I doubt you'll notice the difference that much.


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.