which one is better considering performance, workflow or event receiver?

Question

Using events like ItemAdded, ItemUpdated which one has the good performance on custom list.

What can be preferred considering there are large lists?

Answer 1

Depends on how your requirements fit in 1. Event handlers Can't be manually initiated - workflows can be initiated either automatically or manually.

2. Event Handlers can be Synchronous or Asynchronous - Workflows are always async (They executes after the operation)

3. In Event Receivers we can cancel the operation (such as add/update/delete) - But in Workflows its not possible.

4. Event handlers execute from a Particular WFE, So when some thing goes wrong in that WFE, It may end-up. But Workflow Jobs are robust and can resume even after Reboots.

5. Usually Event handlers runs for short period - Workflows can be longer even for years!

6. There is no User Interface/user Interaction in Event Receivers - Workflows can have user interactions such as getting user input in Initiation forms.

7. As the Name indicates, SharePoint Event receivers are triggered by events like New Item Adding-Added, Updating-Updated, Deleting-Deleted, etc. - But Workflows triggered only on Creation/Change/deletion.

8. Event Receivers are created using Visual studio - Workflows can be via SharePoint user interface, SharePoint Designer, Visio or Visual studio.

9. Workflows leaves "Workflow History" logs which we can refer for debugging - Event handler doesn't do such.

10. Event receivers are better for large volume - Workflows are better for small amount of data.

Answer 2

The initial decision point is if you need the ability to cancel the process. If you do, you should use an event receiver. If you do not need this ability, you must decide whether the business process requires input from users. Another issue is persistence. If the process takes longer than five minutes to resolve, that is another case where a workflow is more appropriate than an event receiver. Finally, if the application is heavily used, you may need to consider using an event receiver instead of a workflow.

http://msdn.microsoft.com/en-us/library/ff648492.aspx

For workflow performance details you can check:

http://msdn.microsoft.com/en-us/library/dd441390(v=office.12).aspx

Answer 3

It would be best to describe the business case.

Workflows and event receivers are entirely different things but unfortunately semi-developers proficient in the SharePoint designer only have come up with all sorts of creative uses for designer workflows.

It would be best to explain what the need is, how big the list is going to be and how many users are going to be accessing the content concurrently.

Answer 4

It really depends on what actions occur when an item is added or updated, how your environment is set up, and whether you are using 2013 Workflow or Legacy Workflow.

Let's assume you want to do something simple, like update the title field. Optionally, maybe you want to update a database.

Event Handlers: Since Event Handlers run in memory on the WFE when the Item is added or Updated, you would expect your code to complete faster. However, this brute force speed comes at the expense of scalability. Too many events may chew up too much memory and cause that WFE to bog down. Furthermore, if your handler code is accessing an external resource (like a database) then that resource will be taxed as well. Be careful.

Legacy Workflow: Legacy workflows (aka SharePoint 2010 Workflows) also run in memory, but it's the timer service that runs it and you can tweak it so that a different server in the farm will take over these actions while the WFE continues to serve up pages. So, it's more scalable. However, the timer service also manages when your code is run and when it decides to sleep etc, so you'll likely see lag time. Also note, if you want to access an external resource, get ready to build that out in Visual Studio as this isn't available OOTB with Legacy Workflow.

2013 Workflow Because 2013 Workflow can run on a separate server (or even high availability farm) that is dedicated to just Workflow, you can say this is the most scalable option. However, get ready for a lot of lag because virtually everything you can do in a 2013 workflow will involve some kind of web service behind the scenes and all the performance overhead that comes with it. If you need to access an external resource, it's fairly straightforward here provided you need to access a web service. Otherwise, you'll need to crack open Visual Studio to build out that interaction.