Hi, could you paste the stack trace from the debugger.

(If you've got criticisms, please re-read the post before posting.)
(This post isn't about the product we're building / built. In it, I am asking for opinions on the design decisions we took. It is why I stayed away from discussing technology specific details and code.)

Hello,

My team's tasked with building a biometrics (fingerprint) enrolment and verification system for one of our clients. I describe as follows.

- The client has, already deployed, a highly customizable PHP application for managing their records
- We have in the past written code to integrate with their PHP app using the framework's integration points so we are familiar with the set-up / code
- The client's preferred browser is Firefox

The fingerprint system (AFIS [Automated Fingerprint Identification System] from this point on) is to work in the browser. With this, we were faced with 2 options for technology to build upon

- JAVA: Java applets using the JVM in the browser (should work in most browsers)
- .NET: XBAP apps using the .NET framework on the client's PC (works well in IE)

We went with XBAP & IE for the following choices (please note we didn't evaluate this same points in much detail for Java)
- The team is strong in C#, .NET & and the Windows platform
- Strong interoperability between the XBAP host and the browser (JavaScript)
- Fantastic technologies on the .NET platform we used:
- LINQ
- Reactive Extensions
- Generics
- Threading
- Task Parallel Library (TPL)
- and more

When we initially thought out the application, we naively imagined building a web request response cycle where an enrollment or verification (E or V) operation hits an ASPX or MVC controller, does a SELECT on all prints & scans the sent print against all the prints in the database returned in the query. Now please don't do this, like seriously!. There are many reasons this is bad:
- this doesn't scale
- this won't scale
- this can't scale

WHY?
Querying AND loading N large number of prints per request context, performing relatively long compute bound operations per print (even though multi-threaded) is slow, and a huge memory hog.

Before describing what we went with, choosing .NET as meant forcing the clients to switch browsers for reasons mentioned above OR...?

We allow the clients continue to use their preferred browser (Firefox today, could be Chrome or Opera tomorrow) while implementing the solution as an XBAP, constrains us to work in IE only, and use cross browser communication to remotely control the IE instance to capture fingerprint samples and raise events when complete. Now to what we built:

From the browser, we send the fingerprint sample to a custom web server listening on a TCP socket (using websockets). The server accepts fingerprint samples in the request and performs actions like
- authentication,
- authorization,
- routing,
- validation
- presence
- cross browser communication

before passing onto the AFIS app (a separate custom app) to perform
- enrollment,
- verification

Now, this is from where on I mainly ask for suggestions.

The AFIS contains the following components:

- The AFIS connection component is a single threaded, event driven server
- A thread pool where threads that service client requests for fingerprint verification or enrollment operation are pulled from and returned to at the end
- The AFIS search component is multi-threaded
- The AFIS app stores the fingerprint samples in a MySQL (Innodb or Memory storage engine still under consideration) database.

This AFIS app is built to be a single long running process that accepts E or V requests, performs in a single request context for ALL clients. Prior to the arrival of the first request, we query all fingerprint samples into a C# Dictionary that is kept in memory, in proc for the time the AFIS app is running, and all searches are performed against the dictionary. Some pre-processing is done on the database records while being transferred into the Dictionary to significantly speed up comparisons against samples in the request.

The Dictionary is kept in sync with the database using a combination of triggers, events and method calls using a read write lock while the Dictionary is being updated with state changes from the database.

Asking for suggestions, and implications further down about what you've read will be appreciated. Thanks.

@OP, code seems light weight from an imagined point of view of what the DOM looks like looking at the code. My advice, continued use of your cached selectors. Also, as you further further further (repetition intentional) progress, begin to decouple the UI elements from the controller actions. You know View, Controller logic separation. Not saying roll or use a client side MVC project, just something like this.

// router
app = $({});

// controller
app.on("pledgeType.change", PledgeTypeDisplay)
app.on("PledgeTypeFrequency.change", PledgeTypeFrequency)

// view
pledgeType.dropDown.change(function () {
app.trigger("pledgeType.change";
});

Also like to know your reason of storing jQuery ref in objects PledgeTypeFrequency, and pledgeType. Scoping I imagine?

---

Errrrr @pc guru, to call out using $("#id-selector", especially for the reason of creating "too many overheads" I'm not sure is valid criticism, coupled with the fact that those calls are one off, at the beginning of the code run, and cached in a variable. Browsers (mine here Chrome 29.0) ran a $("#foo" from your linked test 524,916 times in 1 (one) second. Even IE6 on WinXP should achieve a pretty decent iteration count.

Also jQuery's use would be considered valid considering he runs animations within the script.

@pc guru, just couldn't pass without pointing those reasons out.