36

This is mostly a matter of preference. Using chaining tends to create more readable code, and can actually reduce CPU/heap memory. For example, consider these two snippets of code: // No chaining KeyPair kp = new KeyPair(); kp.setKey(key); kp.setValue(value); Utils.someMethod(kp); // Chaining Utils.someMethod(new KeyPair().setKey(key).setValue(value)); ...


36

I suspect, internally, that this code is written in Apex Code and thus suffers the same general performance problems as doing it yourself. If you want a blazing-fast interface, consider using Type instead: String obj1 = 'Account'; Long time1 = DateTime.now().getTime(); for (Integer i = 0; i < 50; i++) { SObjectType r = ((SObject)(Type.forName('...


29

I created the simplest page in the world, with a custom controller, that looked like this: Generated by <apex:page controller="spinspinspin" action="{!spin}"> <h1>Congratulations</h1> This is your new Page </apex:page> And in the controller I simply had public class spinspinspin { public void spin() { for(...


28

(tl;dr at bottom) Filter Speed If you can use Map.keySet(), you'll get a Set back in about 1/10th of the time versus a loop over those same records and adding all the values. Of course, the Map<Id, SObject>(List<SObject>) constructor only works on Id, not on related ID values, which means you'd have to fall back to a loop. However, in cases ...


25

Great question! Given your data volumes and the overlap in the fields you require. I would go with a single query and thus single result set. Yes your burning some statements but not a huge amount given your volumes. So I would allow yourself to leverage a single query (which is far more constrained resource than statements) and benefit from having a ...


24

Great question. In opening this can of worms, I would like to noodle the premise if you don't mind :-) just to learn if we're solving performance in the right quadrant. What motivates your question exactly? easy problem ^ hard problem easy solution | easy solution | [start here] ...


23

The following methodology may be somewhat faulty but demonstrates a large difference. The get approach is more than 4 times slower. Square Brackets List<Integer> numbers = new List<Integer>(); for (Integer i = 0; i < 1000000; i++) numbers.add(i); Integer x; Long start = Datetime.now().getTime(); for (Integer i = 0; i < 1000000; i++) x = ...


22

I'll play devil's advocate with some reasons you might not want to chain methods. (I'm not necessarily saying a fluent interface is a bad thing, just providing some counter points.) Debugging and error handling Utils.someFunction(new Parameter().setParam9(someVariable).setParam16(anotherVariable).setParam19(weDontHardCodeParametersWhereIComeFrom)); Quick, ...


21

Recommendation Object instantiation is fairly cheap. However, you can make it more efficient in two ways: Set field values using name/value pairs. Don't cache the object, just add it directly to the list. So that would look like: for (Case record : createdCases) { tasks.add(new Task( OwnerId=someValue, Subject='Some other value', ...


21

Today I Learned. From the Spring '17 Release Notes on Allow CSRF Protection on GET Requests to Visualforce Pages (Critical Update): CRSF [sic] checks on GET requests also affect how Visualforce pages are referenced from Apex controllers. Methods that return the URL of CRSF-protected [sic] pages for navigation don’t work: public String getPage() { ...


20

The first is casting. The second is calling a static method on the Id class. One major advantage of the former is that it is more null safe. Id idVal1 = (Id)null; // works Id idVal2 = Id.valueOf(null); // blows up One advantage of the latter is that you can one-line more of your code by calling instance methods on the cast result. You can get one-liners ...


16

Formula fields are determined at read time, as they are not stored in the database. Which can make things slow down when reading the records in some cases. There is a great blog post here on the topic, which does indeed recognise that developers often maintained formula field type information in physical fields calculated at write time in order to avoid this....


16

Do not use SOQL unless you must. If all the data you need to update comes from the child, simply use it sans query. Save governor limits wherever possible in your code. Opportunity master = new Opportunity(Id=detail.Opportunity__c); // child related data update master; Sometimes you actually need parent data, and that is how you should decide when a query ...


16

There are a number of optimizations that could occur here, but none of them are "major." Here goes. Stop Describing! This one may or may not be your main culprit, because you're not caching your describe results, potentially wasting hundreds of milliseconds in CPU time or more, depending on the quantity of record types you have. Map<String, ...


16

When you say "schedule a task", I'm going to assume you're talking about a batch class that performs work. If that's the case, I believe your issue is related to how asynchronous processing works on the platform overall when you have to share resources with other orgs on the same pod. During times of heavy load, when thresholds are exceeded for server ...


15

Most general optimizations don't matter, and you really shouldn't worry about performance terribly, as the other answer said, but I'm going to provide some very specific rules that you should follow regardless: Use Configuration instead of Code, if at all possible. This is simply because code uses execution time, and configuration does not (the 10,000 ms ...


15

Personally I'd go with the code that was the easiest to read (!getErrors().isEmpty() IMHO) and then worry about micro-optimising it if there was a proven performance problem. isEmpty() makes your intentions clearer. That said, why not measure the difference using the Apex Log set to the finest level of logging? (See Caveats below for several reasons why ...


15

Getting the individual describes is significantly faster. Depending on your situation, it is anywhere from 14 to 850 times as fast! Describing Many Objects Once The first continuum I profiled is the situation where you have many objects to describe and make one call to describe all of them. The individual getDescribe approach can describe anywhere from 5 ...


15

You could implement infinite scrolling similar to what I did for my custom Lightning Component that renders data table. In your main component's render.js file attach a listener to the window.onscroll event. As the user scrolls down the page the below code detects once the user has neared the bottom then can take action. In my example, I invoke helper....


15

The difference is how many times equals will be called (and thus, your performance). As an example, let's take a look at the following class: public class KeyTrial { public static Integer eCounter = 0, hCounter = 0; Integer value; public KeyTrial(Integer val) { value = val; } public Boolean equals(Object o) { eCounter++; ...


14

Update: I missed what is probably the single most important part of the question in answering this - the "In SOQL" part. Perhaps consider this answer in terms of the other processing you are going to do with the collection before or after you pass it off to a SOQL query. Summary: Use a List when: Ordering is important You want to access elements by index ...


14

Functionally, there is no difference. These two options return the same data. These functions are mostly the same. From a performance perspective, the static approach is approximately 2.5x faster. I ran 25 trials each of 1,000 calls, and the static approach averaged 20.48 ms (20.48 µs per call), whereas the dynamic approach averaged 51.40 ms (51.40 µs per ...


13

Daniel Ballinger: No, batches do not ever run simultaneously. You are correct, however, that serialization is the culprit here. grigriforce: what's your batch size? If you're doing a million records, and your batch size is 1, then you will serialize/deserialize your state 1M times. Even with a small serialized object, that's gonna hurt.


13

UPDATE, I now cover all four cases and tested in a different org so the raw numbers are different. I agree that isEmpty is superior from a readability perspective. However, out of curiosity I ran each scenario 50,000 times. The size method took .02334 seconds on average , whereas the isEmpty method took .02139 seconds on average. That is a difference of ...


13

Also, use the staging environment to perform stress and performance testing. Note that because the hardware for sandbox in the Force.com platform differs from the production organization hardware, the results of performance testing on sandbox might not match those in production. Nonetheless, performance testing on the staging sandbox can still help catch ...


12

Other Tools. Your tools list is a good one, as is your question! In addition I would recommend you take a look at the Viewstate contents via the 'Show Viewstate in Developer Mode' setting on your user. This enables the following view on your page. Note that you can use 'transient' to control this for information you define in your controller that is ...


12

As with Java, String's in Apex are immutable. Thus string concatenation results in a number of String instances (even for the literal strings) being created on the heap. As we know little about the internals of the Apex runtime (Java is much more open in this regard) its hard to say what impact this has on performance. Though it is a reasonable assumption it ...


12

I know this is not an answer but I don't have enough rep to comment We have experienced this in 2 of our CI ORGs which are mapped to 2 different code bases (one of them hasn't changed in about a month). From what I can see the CPU time limit seems to be coming from the Salesforce String/Matcher classes. Just wanted to give you what I have seen so far, ...


12

You could write a helper method for this type of functionality: public Object flsGet(SObject record, SObjectField field) { return !field.getDescribe().isAccessible() ? null : record.get(field); } With this reusable method, you can now just one-line the check: Contact someRecord = [SELECT Name FROM Contact LIMIT 1]; system.debug(flsGet(someRecord, ...


12

@RemoteAction is the fastest you can go without using API calls. If you don't mind using API calls, the AJAX Toolkit is very slightly faster. That said, a well-written RemoteAction can easily run in 1/20th of a second, which is fast enough for most people. Using Visualforce will never be quite as fast, and it's tricky to get back a raw payload without any ...


Only top voted, non community-wiki answers of a minimum length are eligible