Reducing library size (optimization, packaging)

[danrossi]

Hi nice work with the changes. I have finally updated my helper modules which I will report back soon. It will handle both renderers and handle the correct matrix4 rotation from the three camera now.

However the package filesize has increased. Is there a way to reduce and optimise this ?

There is some uneccessary code I can see I would like to somehow remove ie

https://github.com/GoogleChrome/omnitone/blob/master/src/omnitone.js#L194

I do not need this polyfill

https://github.com/GoogleChrome/omnitone/blob/master/src/polyfill.js#L67

I obtain an audio context from three.js code which provides a polyfill ie

getContext: function () {

		if ( context === undefined ) {

			context = new ( window.AudioContext || window.webkitAudioContext )();

		}

		return context;

	},

Is there anything else that could be stripped out ? Should I make a fork to do these myself ?

[danrossi]

There is other bloaty logger methods that could go too.

[danrossi]

Stripping out uneccessary code bought it down 10kb already. I believe if this is changed to es6 and using rollup. It will reduce the bloat caused by webpack and the module code also ?

[danrossi]

There is too many instances of logging code. not sure how to do conditional packaging. But a non debug version would be of interest.

[danrossi]

not using webpack would be a bonus as its bloaty but this conditional support could be of interest

https://github.com/webpack/docs/wiki/list-of-plugins#defineplugin

[danrossi]

This is a proof of concept using the defines plugin. It was a bit of a wasted effort but after removing all debug logging and the polyfill which was in many places. It only recovered 4kb now sadly. Its a start.

https://github.com/danrossi/omnitone/tree/81-conditional-support

[hoch]

@danrossi Dan - thanks for looking into this but please take a look at these first.

https://github.com/GoogleChrome/omnitone/releases/tag/1.0.5
#71

The actual library size of ~40kB is a nice compromise considering it doesn't rely on XHR loading any more. Other VR projects consistency have been requesting this feature. Still, I agree with your point on redundant codes and any optimization PR is welcomed!

(I also renamed the issue accordingly.)

[danrossi]

Removing the logging didn't really take it down much. Maybe it's the base64 files taking up space. I guess nothing can be done about that.

What I can do is selective load into my app instead of bundle it. I know it's bloaty too but I use a trimmed down version of three.js with a custom build only including what is needed. It brings it down to 350kb and could go further removing all the shaders built in.

Maybe close this , unless that conditional support branch is useful ?. It's a pretty big edit , ie conditional constants are required around all of the logger sections.

My build here is 49kb. There was a problem with checking out it seems and the older code built at 55kb. The original was 19kb is all. How do I get 40kb ?

[danrossi]

I don't know if those changes are useful or else close it.

I've had to remove it from the bundle and sideload on demand when required like with the webvr polyfill. The app will load them.

I don't know if much improvements can be made with the size. I thought I took out more at first.

This will serve the purpose.

[danrossi]

You may close this if you wish.

I have the omnitone files side loading on demand in the project. So not bundled.

I have just figured out another three bundling optimisation that will strip out all the bundled shaders that are not needed. And the custom main file only exports the required modules. So has reduced it down to 260kb .

[hoch]

@danrossi I want to use this as a tracking entry for all file size reduction issues.

FWIW, 1.2.1 stripped out all of deprecated FOADecoder stuff including outdated HRIR files. Also Omnitone will be served via Google's CDN in the near future, just so you know.

[danrossi]

Ok not a problem. It might not be the best to attempt a PR from my branch. But you can see how compiler conditionals work to strip out all logging. It only reduced it by 4kb though .

It might be a possibility then of side loading like any other api like youtube api from their cdn etc.

[hoch]

I am not completely satisfied with the file size in 1.3.0, but it's what we have. Please open a new issue if you think there's more can be done.

[danrossi]

That's ok not a problem. I'm now selective including the library now.