For DyKnow 5.2, as I often mention, we totally rewrote the DyKnow panel to be more stable and more WYSIWYG (specifically the rendering of text). Because of a few of the technology choices we made along the way, we also saw an increase in performance. In fact we saw a major increase in performance. As promised (last year) I ran through some benchmark tests for drawing notebooks to share just how much performance we've gained in 5.2. In my benchmark ink test, DyKnow 5.1 drew the panel in an average of 4.3 seconds. DyKnow 5.2 however, drew the panel in an average of 1.7 seconds. In my benchmark text and images test, DyKnow 5.1 drew the panel in an average of 4.6 seconds with a standard deviation of 3.1 (the range was 2.8 to 11.8 seconds). DyKnow 5.2, however, averaged 0.3 seconds with a standard deviation of 0.1 seconds (the range was 0.2 to 0.6).
Additionally, 5.1 was much less responsive when performing actions such as zooming and scrolling around panels. So 5.2 came out and we developers felt very good about the increased performance. And then something very interesting happened. Now that the client was running so much faster when dealing with lots of ink, we noticed notebooks that contained lots of ink. Significantly more ink than what we'd seen in the past. We're talking zooming the client to 250% zoom and writing as small as you can to cram in as much as possible. These were not the usage patterns we'd seen before.
Now we started looking at the time it took to save all this ink when saving your notebooks. Based on some of your feedback and this new usage data, we found a few ways that really sped up save times and put out a server patch with these improvements. But we haven't stopped there. Following our initial stress test for DyKnow 5.3, we implemented changes to improve performance when submitting or retrieving very large panels in a Session. We're also working on ensuring institution-wide scalability for our new file request feature (speaking of pushing lots of data). For the past few weeks, it has been all about squeezing out as much performance as possible, especially under these high load situations. And this is how DyKnow can be used to engage an entire lecture hall with hundreds of students. It's a continual push but so worth it.
Additionally, 5.1 was much less responsive when performing actions such as zooming and scrolling around panels. So 5.2 came out and we developers felt very good about the increased performance. And then something very interesting happened. Now that the client was running so much faster when dealing with lots of ink, we noticed notebooks that contained lots of ink. Significantly more ink than what we'd seen in the past. We're talking zooming the client to 250% zoom and writing as small as you can to cram in as much as possible. These were not the usage patterns we'd seen before.
Now we started looking at the time it took to save all this ink when saving your notebooks. Based on some of your feedback and this new usage data, we found a few ways that really sped up save times and put out a server patch with these improvements. But we haven't stopped there. Following our initial stress test for DyKnow 5.3, we implemented changes to improve performance when submitting or retrieving very large panels in a Session. We're also working on ensuring institution-wide scalability for our new file request feature (speaking of pushing lots of data). For the past few weeks, it has been all about squeezing out as much performance as possible, especially under these high load situations. And this is how DyKnow can be used to engage an entire lecture hall with hundreds of students. It's a continual push but so worth it.
Powered by Compendium Blogware
Comments for the continual push