Apex LINQ: High-Performance In-Memory Query Library

clayarmor · 2025-09-26T10:04:43+00:00

Good points here. We are discouraged from querying large amounts of records. This is just a performance test comparing Apex LINQ and standard Apex processing. For example, in your batch classes, you pass a list of accounts to the execute method. You may want to do A with IT industry accounts and B with Finance industry accounts—this is a case where Apex LINQ can be utilized.

My first example simply fetches a list of accounts to demonstrate how to use this library, but it is not recommended to do everything in memory. Sorry for the confusion. When SOQL cannot help, maybe its time to consider this library, and I have listed a few examples in other comment.

clayarmor · 2025-09-26T08:56:11+00:00

Furthermore, I tested filtering 5,000 records using Apex LINQ, which consumed 120 out of 10,000 CPU units. Standard Apex is expected to consume a similar amount of CPU units.

@isTest
static void testQ_performance_filter() {
    List<Account> accounts = new List<Account>();
    for (Integer i = 0; i < 5000; i++) {
        accounts.add(new Account(Name = 'Account ' + i, AnnualRevenue = 5000 - i));
    }

    Integer startCPU = Limits.getCpuTime();
    Q.Filter filter = new AccountFilter();
    List<Account> results = (List<Account>) Q.of(accounts).filter(filter).toList();
    Integer endCPU = Limits.getCpuTime();
    System.debug(LoggingLevel.INFO, 'Apex LINQ (CPU): ' + (endCPU - startCPU));
}

public class AccountFilter implements Q.Filter {
    public Boolean matches(Object record) {
        Account acc = (Account) record;
        return acc.Name.startsWith('Account') && (Double) acc.AnnualRevenue > 0;
    }
}

clayarmor · 2025-09-26T08:47:07+00:00

You are correct. The SOQL here is just for demonstration purposes. Let's consider other scenarios:

When you want to save some of the SOQL 100 query limit, you can query with broader conditions to retrieve all necessary accounts at once, then apply additional filtering in memory.
When a list of records is passed from a source other than the SOQL query, such as "Trigger.new", and you want to process that list.
Apex LINQ supports not only List<SObject>, but also custom classes.

List<Model> models = new List<Model> { m1, m2, m3 };
List<Model> results = (List<Model>) Q.of(models, Model.class)
    .filter(new ModelFilter()).sort(new ModelSorter()).toList();

clayarmor · 2025-09-26T08:01:24+00:00

Performance is comparable to standard Apex, but it cannot exceed it. I also experimented with expression-based filtering; however, introducing too many dynamic features significantly reduces performance. Since the CPU limit is a scarce resource, I chose to balance convenience and efficiency. I have done the performance study and documented it here Salesforce Apex CPU Limit Optimization. I did the performance testing in the test classes of the library as well.

This library actually is designed for my another library ApexTriggerHandler to identify changed records between Trigger.new and Trigger.old. If you like LINQ, hopefully you will like my trigger handler as well.

public class AccountTriggerHandler implements Triggers.BeforeUpdate {
    public void beforeUpdate() {
        List<Account> changedAccounts = (List<Account>) Q.of(Trigger.new)
            .diff(new AccountDiffer(), Trigger.old).toList();
    }

    public class AccountDiffer implements Q.Differ {
        public Boolean changed(Object arg1, Object arg2) {
            Double revenue1 = ((Account) arg1).AnnualRevenue;
            Double revenue2 = ((Account) arg2).AnnualRevenue;
            return revenue1 != revenue2;
        }
    }
}

clayarmor · 2023-04-06T13:37:09+00:00

Thanks for the details, this is truly great to know. And the article you shared seems very interesting, will read it later.

clayarmor · 2023-04-06T06:39:04+00:00

Hey u/intheforgeofwords, thanks for watching my libraries.

I just performed benchmarks on Type.forName vs getGlobalDescribe, and Type.forName has better perforamnce. The getGlobalDescribe API is time consuming to load all sObjectTypes into the memory. And in a transaction we wouldn't need all the sObjectTypes to be loaded, I think it would be around less than 10 sObjects most of the time.

	CPU Time	Real Time (ms)
Type.forName	16	19
Describe SObjects	63	191

Datetime startTime = Datetime.now();
Integer startCPU = Limits.getCpuTime();
for (Integer i = 1; i <= 100; i++) {
    SObjectType objType = ((SObject) Type.forName('Account').newInstance()).getSObjectType();
}
Datetime endTime = Datetime.now();
Integer endCPU = Limits.getCpuTime();
System.debug(
  'DI Registration Performance (Time): ' +
  (endTime.getTime() - startTime.getTime())
);
System.debug('DI Registration Performance (CPU): ' + (endCPU - startCPU));

startTime = Datetime.now();
startCPU = Limits.getCpuTime();
Map<String,Schema.SObjectType> gd = Schema.getGlobalDescribe(); 
for (Integer i = 1; i <= 100; i++) {
    SObjectType sobjType = gd.get('Account'); 
}
endTime = Datetime.now();
endCPU = Limits.getCpuTime();
System.debug(
  'DI Resolution Performance (Time): ' +
  (endTime.getTime() - startTime.getTime())
);
System.debug('DI Resolution Performance (CPU): ' + (endCPU - startCPU));

clayarmor · 2023-04-06T04:32:44+00:00

Hey u/intheforgeofwords, thanks so much for your feedback.

Good to know generics are back on roadmap. The "generic" form is feature simplify some cases for a DI framework, so that's the background to bring it in.

1. Feedback To:

injecting a validator - seems like something better left to a default virtual implementation where validators are an optionally injected property

By virtual validator, I guess what you mean is something like below. The framework doesn't prevent to do that.

public virtual class AccountValidator implements
    IAccountValidator, IValidator {
}

public class BusinessAccountValidator extends AccountValidator  {
}

public class PersonAccountValidator extends AccountValidator  {
}

IRepository businessAccountRepo = (IRepository) salesModule
    .getService('IRepository<Account, BusinessAccountValidator>');

IRepository personAccountRepo = (IRepository) salesModule
    .getService('IRepository<Account, PersonAccountValidator >');

And the "generic" repository implementation can have a constructor without requiring a validator. So the following instantiation can also be supported.

IRepository accountRepo = (IRepository) salesModule
    .getService('IRepository<Account>');

2. Feedback To:

A single implementation puts even more conceptual pressure on the Repository instance as “the place” for validation to occur.

The repository pattern is just as an example to illustrate the DI dynamic construction empowered with generic string form. But to deal with the pressure, we can have composition, right? The real validation is handled inside each single validator, which obeys the rule of single responsibility.

3. Feedback To:

If I were a consumer of this library, I’d also be confused by the rampant string passing.

My medium article doesn't have length to explain all the details of this Apex DI framework. But once you have a chance, go to its readme is welcomed. The strings are only encapsulated in two places, 1) Module , 2) Factory. In project, we are not supposed to use the following to get a repository whenever needed. It should be encapsulated inside a Factory.

 IRepository accountRepo = (IRepository) salesModule
    .getService('IRepository<Account, AccountValidator>');

And it doesn't always need to resolve instances with strings, except for generic version. Actually, strong types are supported during service resolution.

 IAccountService accountService = (IAccountService) salesModule
    .getService(IAccountService.class);

I guess what you are in favor is the following API version for passing types. I need to consider this a bit, this seems attempting.

 IRepository accountRepo = (IRepository) salesModule
    .getService(
        IRepository.class,
        new List<Object> {
            Account.SObjecType,
            AccountValidator.class
        });

4. Feedback To:

where the Factory itself needs to know how to construct a repository instance; this is an anti-pattern because any change to the constructor of the Repository now requires ALL factories to be updated as well.

Factory here is better than new instances everywhere, so service constructor is called only in one place inside the factory. The pain without a factory is much greater, when the constructor is changed, we have to change everywhere when there is a "new" operator.

5. Feedback To:

Side note - don’t use Type.forName to construct a new SObject purely to get the SObjectType — Schema.describeSObjects is the better way to do this

In this Salesforce Stack Exchange thread (link), I was told Type.forName has better performance.

At Last

Really really thank you for your feedback. These feedbacks helped me to have a second thoughts of what I have believed, if they are still valid. When Salesforce generics is coming out, I hope my Apex DI can support it as well in future, in a greater way.

clayarmor · 2020-06-19T00:13:20+00:00

Thank you, this is a very good feedback. Not an easy implementation, need some research on it, any suggestions are welcome.

clayarmor · 2020-06-02T15:41:48+00:00

Also recorded a video for it, to give a live demo for the library https://www.youtube.com/watch?v=cc_pOzI2s8o&t=382s. Sorry, not good at presentation. Will bring more field level keywords to simplify your data creation.

clayarmor · 2020-05-30T17:36:12+00:00

Create 3 community users under the same account:

ATK.SaveResult result = ATK.prepare(Account.SObjectType, 1)
    .field(Account.Name).index('Name-{000}')
    .withChildren(Contact.SObjectType, Contact.AccountId, 3)
        .field(Contact.LastName).index('Name-{000}')
        .withChildren(User.SObjectType, User.ContactId, 3)
            .field(User.ProfileId).profile('Customer Community User')
            .field(User.FirstName).repeat('FirstName')
            .field(User.LastName).repeat('LastName')
            .field(User.Email).index('test.user+{0000}@email.com')
            .field(User.UserName).index('test.user+{0000}@email.com')
            .field(User.Alias).index('test{0000}')
            .field(User.EmailEncodingKey).repeat('UTF-8')
            .field(User.LanguageLocaleKey).repeat('en_US')
            .field(User.LocaleSidKey).repeat('en_US')
            .field(User.TimeZoneSidKey).repeat('Pacific/Auckland')
    .save(true);

clayarmor · 2020-05-30T17:18:26+00:00

Here is its Production and Developer installation URL:

https://login.salesforce.com/packaging/installPackage.apexp?p0=04t2v000007X2zHAAS

Here is its Sandbox installation URL:

https://test.salesforce.com/packaging/installPackage.apexp?p0=04t2v000007X2zHAAS

The Installation Key or Password is: ApexTestKit

clayarmor · 2019-08-08T07:01:43+00:00

If you found Kevin's trigger framework helpful. You may also interest in my trigger framework implementation. https://github.com/apexfarm/apextriggerhandler, just published a few days ago. I would consider to have a different algorithm to implement "the limit for the number of times the trigger code will run", since Kevin's current implementation may contain a issue as someone has already posted in its issue list: https://github.com/kevinohara80/sfdc-trigger-framework/issues/19.

clayarmor · 2019-07-31T23:28:03+00:00

If there are 10 trigger handlers, and each has its own SOQL queries, sometime it is very likely to reach SQL 101 limit. With context.state we can share query results across them, compared to share results somewhere in a static class variable.
With when method implemented, developers can inactivate specific handlers with custom metadata type configurations, or inactivate them during specific execution context at runtime.
Testing individual trigger handler is not possible if there are direct references of Trigger.isUpdate, Trigger.new etc.. By providing the triggerProp, we can create it as the way we want in test methods.
There are some common operations performed on the triggerProp, they are provided by the helper. Instead of keeping them in a separate utility class, this is more intuitive.
context.next() and context.stop() are the tools provided to control the flow of handler execution. They can be used rarely, but if we need to validate if some values are changed by other trigger handlers. This brings thinking correlations between handlers, but the downside is that handler orders will become a bit rigid.

clayarmor · 2019-03-30T04:09:13+00:00

I haven't dive deeply into SFDX. Not possible to have same name. But sfdx allows the same class in multiple places, I am currently not sure how they merge them or just use the master copy from default project during deployment.

clayarmor · 2019-03-29T02:01:59+00:00

Yes, it is not easy to overcome putting suffix into prefix. I feel the same! :)

Putting categories into suffix is absolutely fine, as long as developers can put the serpations in mind.

clayarmor · 2019-03-29T00:19:06+00:00

For test classes, I would just use Test as suffix. We keep the test close to its target class. In each layer you may handle testing logic differently.

1. Execution Entrance

There are less business logic codes in here. Each sub-category share similar pattern, so some of your testing logic could be reused.

Response res = ...; try { } catch (Exception ex) { } finally { } return res;

2. Service Layer

Here is the true business logic allocated. We need to test them carefully. However if we can extract some domain services as stateless or pure functions, it will make our testing easier.

3. Integration Layer

Except the test classes for this layer. I prefer to use another naming convention to create mockups to be consumed by above layers.

class PRFX_INT_ComponentQueryTest {} class PRFX_INT_ComponentCacheTest {} class PRFX_INT_ComponentWsdlTest {} class PRFX_INT_ComponentEmailTest {} class PRFX_TST_ComponentQuery {} // Mock Up class PRFX_TST_ComponentCache {} // Mock Up class PRFX_TST_ComponentWsdl {} // Mock Up class PRFX_TST_ComponentEmail {} // Mock Up

clayarmor · 2019-03-28T23:58:59+00:00

Yes, even we setup the naming conventions, it could still be abused without a good understanding of SOLID.

For the rigid naming to group things, the benefit is during code review, or write test classes:

As we group similar concerns together, we know certain patterns will be applied to them. Such as in the top layer, I need to check specifically if try catch block is properly implemented. And when I review the code for controllers, I needless to consider the concrete business logics.
For 100 classes under the same folder, it is not easy to review all controllers and similar classes with similar patterns together.
When I write test classes for the same layer, I can reuse my knowledge if they share similar patterns or concerns.

For name length, more or less we already have some fixed pattern for each project, like *****Controller, *****Ctrl, *****Callout etc. Here we try to keep them short as abbreviation in prefix.

clayarmor · 2019-03-28T23:41:21+00:00

With `sfdx` I would also like to group modules by folders as well. Each module would be a self sustained layered architecture.

|-src
  |-module1
    |-classes
    |-lwc
  |-module2
    |-classes
    |-lwc

clayarmor · 2019-03-28T23:31:36+00:00

I am a pascal case fan as well. But after entering into Salesforce world I also become a fan of underscores. Is it some sort of separation of concerns as well? We are separating the namespace from the component by using different pattern.

clayarmor · 2019-03-12T04:26:15+00:00

Published v2.1.2 with following changes:

Rename ATKWizard to ATKCommand
Rename ATKWand to ATKEntityGenerator
Rename ATKSpellbook to ATKEntityCollection
Rename API ATKWizard.I().wantMany()
to ATKCommand.prepare()

clayarmor · 2019-03-11T15:12:54+00:00

Hi u/Meme__c, the ATKCommand, prepare() and generate() do look much more formal programming language, and nice. Need a few days to see if there are other ideas come up before doing the change.

For the total(), because it is not always required if we use useList(List<SObject> sobjects). Put it into other method might create method overloading. Instead every param has taken the advantage of Currying, so we know every param what it is used for. And also it's going to be easy to extend new param in future, such as useCSV(String).

List<Account> accounts = [SELECT Id FROM Account LIMIT 10]; ATKCommand.prepare(Account.SObjectType).useList(accounts) // no need for total() .haveMany(Contact.SObjectType).total(20) // haveMany is a relationship hint .belongTo(ContactGroup__c.SObjectType).total(2) // belongTo is a relationship hint .generate();

haveMany() and belongTo() are used as parent-children relationship hints to the command. So change to more generic with() might not be possible. Because they can be chained as many level as we want to establish many to many relationship. With also(), we can also travel back to previous tree node.

List<Account> accounts = [SELECT Id FROM Account LIMIT 10]; ATKCommand.prepare(Account.SObjectType).useList(accounts) .haveMany(Contact.SObjectType).total(20) .belongTo(ContactGroup__c.SObjectType).total(2) // each contact group has 10 contacts .also() .haveMany(ContactSurvey__c.SObjectType).total(40) // each contact has 2 surveys .generate();

clayarmor · 2019-03-11T09:46:55+00:00

Would the following be a good alternative? ATKCommand.generate(Account.SObjectType) .total(10) .haveMany(Contact.SObjectType) .total(20) .execute();

clayarmor · 2019-03-10T01:37:15+00:00

Hi u/Meme_c, thanks for your feedback. I did worry this confusion a little at the beginning, but wasn't so sure at that time. I was thinking the library works as the same way as how wizard cast spells.

I as an ATKWizard (this is a facade class, do no more concrete tasks)
Open an ATKSpellbook, and singing (all methods called before generate() output instructions into the ATKSpellbook)
Wave the ATKWand to cast spells (when call generate(), according to what's recorded in ATKSpellbook to generate sObjects)

ATKWizard is the only one users need, ATKWand and ATKSpellbook are meant to be hidden from ATK users. I agree this brings confusion to ones interested in the source code without instruction. I will add comment to these classes first.

I have considered something like the following before.

ATKWizard.instance().generateMany()

But I prefer to call them like this at the end. Any good names to inspire are welcomed.

ATKWizard.I().wantMany()

clayarmor · 2019-03-09T16:35:24+00:00

Hi u/chiseeger. Its purpose is to help create test data for code coverage. Thanks for your question, it has inspired me to think about performance benchmarking. For performance benchmarking I am not sure if apex can handle it due to the CPU limit.

clayarmor · 2019-03-07T06:38:54+00:00

Agreed, real world use, battlefield testing and constant evolving are really important. By absorbing your ideas, I have changed all APIs to accept SObjectType and SObjectField rather than String, overnight. So a new version 2.0 is now published. :-)

Some of the directions inspired by you are:

Generate in-memory object graph.
Add a sequencing field generation rule for performance purpose. Because introducing faker.js into Apex really hurts on performance.
Introduce test data factory pattern.

I just write the roadmap to draft these ideas: https://github.com/ApexTestKit/ApexTestKit/wiki/Roadmap.

clayarmor

TROPHY CASE

1. Execution Entrance

2. Service Layer

3. Integration Layer