[Ur] A few questions about Ur/Web

[Adam Chlipala]

On 07/21/2014 12:15 PM, Andy wrote:
> New to Ur/Web. This looks like a very interesting project. Would love 
> to try it out. Have a few questions:
>
> 1) The FAQ states "From the world of dependent types, Ur/Web takes 
> type-level computation." Does that mean Ur/Web have full support for 
> dependent type? If not, what is missing? Anything that the type system 
> of ATS or Agda can do that the type system of Ur/Web can't, or vice versa?

No, I say that Ur/Web doesn't support dependent types.  For instance, 
types are not allowed to mention variables whose values are not known 
until runtime.

> 2) Looking at the Techempower benchmark, for the "Multiple Queries" 
> and "Fortune" tests, the performances of Ur/Web-Postgresql are several 
> times higher than that of Ur/Web-MySQL. This is really strange because 
> for almost all other frameworks the exact opposite is true: MySQL 
> results tend to be much higher than postgresql results. Is this due to 
> some problems with the urweb mysql driver? Any workaround? All my data 
> is on MySQL so the poor performance on Mysql is a concern.

Can you point to particular parts of the TechEmpower datasets 
demonstrating that MySQL tends to give better performance than 
PostgreSQL?  I only see small differences for other frameworks.  In 
general, I think Postgres is much better at scaling to high concurrency, 
and the 40 hardware threads of the primary hardware platform for these 
benchmarks probably qualifies.  I'm not yet convinced that there is 
anything exceptional about MySQL performance with Ur/Web.

I really do suggest using PostgreSQL with Ur/Web.  The true serializable 
transactions represent a substantial advantage in programming-model 
simplicity vs. MySQL.

> 3) For the "Data Updates" benchmark Ur/Web has poor performances with 
> high latencies. The FAQ attributes this to "optimistic SQL concurrency 
> thrashing to provide the transactional semantics that most benchmark 
> entrants don't bother to shoot for." Can you get into more details 
> about this concurrency thrashing and why does it cause poor update 
> performance? Is there anyway to turn this off and just use the 
> "normal" semantics that other frameworks use? My application is 
> write-heavy and latencies measured in seconds are just too high.

I think any explanation of database concurrency-control mechanisms 
should get the basic idea across.  Under high contention for rows being 
written by many threads, transactions often need to be aborted and 
restarted, to avoid producing anomalies where transactions don't appear 
atomic.

That particular benchmark is highly unrealistic (for most applications), 
with 40 hardware threads simultaneously running transactions with 40 SQL 
operations apiece (half read, half write). I'd be happy to comment on 
your particular workload, if you can give more detail.  Even better, I'd 
be happy to help build a small benchmark application inspired by your 
workload, so that we don't need to speculate about performance.

If your application is popular enough that this level of 
performance-tuning matters, then you've probably made it to the big 
time!  (And I'll be especially motivated to help you apply Ur/Web 
therein. :])

> 4) How big is the size of the javascript code generated by Ur/Web 
> compared to hand written JS code? For example Dart-generated js tend 
> to be several times bigger than the comparable hand written one. Is 
> Ur/Web similar to that?

Client-side code is shipped as "bytecode" in JavaScript datatypes. I 
don't have a rough size-conversion factor in mind, but you can look here 
for all the recursive function definitions used in client-side code in 
the currently posted main demo:
     http://www.impredicative.com/ur/demo/Demo/app.1404481194191.js
See the very bottom segment for these definitions, on roughly one line 
per function.

Again, to answer this question for your specific application, I'd be 
happy to help build a proof of concept that can be measured!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20140722/3ab36fbf/attachment.html>