Prototype Pattern vs. Revealing Prototype Pattern Memory Benchmark

Last week I benchmarked the Prototype Pattern and the Module Pattern in this post. This week I will add the Revealing Prototype Pattern to the list of benchmarks.

The Revealing Prototype Pattern is a hybrid of the Prototype Pattern and the Module Pattern. It is supposed to be the best of both worlds. The module will have private variables and functions and will only expose a public API while still conserving memory.

As you will see the memory used is very close to the Prototype Pattern. If the style of code you write uses the Prototype Pattern then switching to the Revealing Prototype Pattern will give you the benefits of private variables and functions with minimal memory cost.

Listed below are the benchmarks and code.

Table of Results:

Objects Created	Prototype Pattern Memory (MB)	Module Pattern Memory (MB)	Revealing Prototype Pattern Memory (MB)
1	0.001832	0.002624	0.001832
5	0.003224	0.004232	0.003296
10	0.003552	0.005552	0.003624
100	0.009320	0.031480	0.009392
1000	0.079240	0.294816	0.079400
10000	0.298288	2.378696	0.298544

Prototype Pattern vs. Module Pattern Memory Benchmark

I watched Jonathan Mills Pluralsight course Practical Design Patterns in JavaScript, which is about a few of the Gang of Four design patterns. His demo on the memory usage of the Flyweight Pattern inspired me to benchmark the memory usage of the Prototype Pattern in contrast to the Module Pattern.

One of the pro’s of the Prototype Pattern is to reduce memory because functions are on the object’s prototype. When new objects are created then memory is conserved because the new object’s functions all point to the parent object. In contrast, the Module Pattern creates new objects and functions. There are other pro’s and con’s to using each pattern, but I would like to only focus on the memory usage of each pattern.

Taking Jonathan's snippet of code that measures memory, I repurposed it to measure the Prototype and Module Pattern. I have included the code that I used to measure memory as well as a table of the results of a few test runs.

I hope this benchmark can help you decide when to use each pattern.

Table of Results:

Objects Created	Prototype Pattern Memory (MB)	Module Pattern Memory (MB)
1	0.001832	0.002624
5	0.003224	0.004232
10	0.003552	0.005552
100	0.00932	0.03148
1000	0.07924	0.294816
10000	0.298288	2.378696

How to use Code Katas in Deliberate Learning

I recently watched Dan North's video on Deliberate Learning vs. Deliberate Practice and I wholeheartedly believe in almost everything he said. I do believe that we should really know how to learn as efficiently as possible, which is different for each person. I also believe that we should go to meetups, listen to podcasts and various other methods of quickly learning what the trends are and what the new tech is at a shallow level. Then we can prioritize what we want to dig deeper into and learn more about.

What I did not fully agree with is that code katas were not the way to achieve deliberate learning. (https://youtu.be/SPj-23z-hQA?t=362) On their own katas and the metaphor may not be the right thing we need, but if you take the coding challenge tool itself and apply it in a different way then the kata will be more effective.

For example, the JavaScript group I am apart of at Sogeti has started a weekly coding challenge based on CodeWars katas. While I agree that development is not about writing the same code faster, it is about writing more maintainable, performant, SOLID, and clean code. The first time I write code to solve a problem will probably not be the best solution. I can then look over my code and compare it to other solutions and see if I can use built in functions, break out functions into smaller functions that make more sense, or use recursion.

I am currently learning about JavaScript arrays and the built in functions. As I complete these challenges I am going back and looking for places where I can use these built in functions. Instead of writing loops I can just use what is available. I’m learning to use what is in the language instead of reinventing the wheel. This can also be done when learning the new features of ES6.

I have also started a brown bag meeting to discuss our solutions as a group the day after a coding challenge is finished. At this point, we become the sensei and teach other what could have been done in a more efficient way or if a function or variable could have been written in a more readable manner. This code review is where the real value lies in doing code katas.

Dan North mentioned “Learn Python the Hard Way”, which is a series of exercises that force you to code and learn the python language. This is very much the same style of learning that I want to achieve except that I would like developers to redo the same exercise with a new way that they just learned. This would cement the new way in their mind.

Next time I start a new project and I have to write code that is similar to something I wrote, I will now be confident that I am aware of different ways of writing that code. I will also be confident that it is more readable, maintainable, and performant.